[Kde-pim] Akonadi design questions

[Volker Krause]

On Wednesday 06 June 2007 23:54:40 Christian Schaarschmidt wrote:
> Am Freitag, 1. Juni 2007 08:55 schrieb Volker Krause:
> > On Wednesday 30 May 2007 23:52:10 Christian Schaarschmidt wrote:
> > > I have put toghether yet another overview for akonadi I had planed to
> > > attach. Unfortunately umbrello will no longer display the diagram and
> > > the .png is to big as attachment. Does anyone have an idea how I could
> > > convince umbrello to display it again?
>
> well, this took longer than expected. I switched to argouml and the first
> thing that happend was that my archive got corrupted, at least this was
> fixable... anyway I've attached the result. It might not be 100% UML, but
> shows the big picture. If you think this could be interesting for others I
> can upload it.
> The question is where?
> I'm not sure if is better to start something in
> http://techbase.kde.org/Projects/kdepim/(akonadi?) or to upload it to the
> doc directory?
> techbase could be used to list q&a, todos from this thread, links to
> related projects, etc.
> but it makes only sense if we all agree to keep those things in techbase.
> (if I'm not the only one that thinks this could be worth a try, I would
> volunteer to provide a first shot.)
>
> > > Now to the akonadi questions ...
> > >
> > > there are some aspect I still don't understand, I hope someone on the
> > > list can help providing answers to these questions:
> > >
> > > - What is the idea behind SearchProvider?
> > > MessageSearchProvider does listen to notifications and updates the meta
> > > data accordingly. I guess this is not in eg. AppenJob to avoid code
> > > replication?
> >
> > Search providers were part of one of the first designs and were removed
> > some time ago already. Unfortunately some of their obsolete
> > infrastructure has been used for the strigi and nepomuk feeder agents. We
> > need clean this up.
>
> clean up means rename to feederAgent?

renaming, and also killing the remaining parts of the search provider 
architecture. I think there are eg. still parts in the control process for 
managing them, which duplicates the resource stuff in large parts.

> > In theory you could put this functionality in the item modifcation job
> > classes, but the a separate agent makes it IMHO much more flexible and
> > robust. You can easily add additional agents for your favorite desktop
> > search service and if it crashs because it fails to parse some broken
> > data it doesn't affect your applications.
>
> you are right, I was just wondering about performance issues for
> interprocess communication. some time ago I had a discussion because I
> wanted to add a virtual method in kdelibs. I had to change it because of
> the price of virtual methods ...

Yes, we definitely need to keep an eye on performance, and this of course gets 
harder if you have multiple processes.

> > > - how to search for messages? only Nepomuk?
> > > SearchProvider does not provide message specific searches,
> > > findMessageBySubject or something like that.
> >
> > The idea so far is (IIRC we don't have code for that yet) to pass through
> > the search query to strigi/nepomuk and to the resources which can do
> > searches on the server (eg. ldap, imap). XESAM seems to contain a pretty
> > comprehensive query language which should cover all our needs and
> > wouldn't need any conversion to query strigi (or any other search service
> > supporting it).
> >
> > > -Table PersistentSearches missing
> > > where is PersistentSearch used?
> > >
> > > - is PersistentSearch::uids correct?
> > > SearchProvider does not have member queryForUids( well, I couldn't find
> > > it) QList<QByteArray> PersistentSearch::uids( const DataStore *store )
> > > const {
> > >   return mProvider->queryForUids( mQuery, store );
> > > }
> >
> > Again, this is code from the early search provider design which for some
> > unknown reason is still in there...
> >
> > > - reason for not having Q_CLASSINFO
> > > in control/SearchProviderManger, control/ProfileManger
> > > control/AgentManager does have it.
> >
> > I think it's only strictly needed when you don't use a dedicated DBus
> > adaptor class or generate the interface description from the header file.
>
> hmm, this is confusing.

regards
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070610/2bcda314/attachment.sig>
-------------- next part --------------
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/