I&#39;ve had an idea.<div>It&#39;s possibly controversial.</div><div><br></div><div>The current state:</div><div> - KPeople relies on ktp-common-internals because we have a lot of useful code we don&#39;t want to reproduce.</div>
<div>global-contact-manager, KTp::Contact itself with logic for working out shared capabilities and gabble workarounds, and listing actions etc. We are now able to dynamically list all actions including stream/dbus tubes we want to be able to do that in all places.</div>
<div><br></div><div><br></div><div>Apol (correctly IMHO) thinks this is a problem as kpeople should be entering as a framework without a dependency on ktp-common-internals. This is probably a requirement if we want to be used in PIM.</div>
<div>Long term I want the switching between kpeople and contact-list-model to be done behind the scenes, which means k-c-i has to depend on kpeople. This would be a circular dependency.</div><div><br></div><div>Option 1:</div>
<div> - we duplicate a tonne of code (bad)</div><div><br></div><div>Option 2:</div><div> - kpeople has a plugin infrastructure.</div><div>we only need ktp-common-internals at runtime. </div><div><br></div><div>So what if it went like this:</div>
<div><br></div><div>kpeople builds a model. Then it loads a set of plugins (passed as a stringlist to the constructor) this can set a QIdentityProxyModel (like we use at the moment)</div><div>The telepathy part of kpeople can then reside in our repository as a kpeople plugin</div>
<div><br></div><div>This would also allow for us to add actions easily, and would allow other people to extend kpeople too with any actions or UI components or anything.</div><div><br></div><div>It&#39;s not a lot of work mostly moving some things, and a design that I think is pretty clean, simple and extensible.</div>
<div><br></div><div>David</div><div><br></div>