[Kde-pim] Akonadi datamodel questions

[Volker Krause]

On Sunday 27 May 2007 17:48:37 Christian Schaarschmidt wrote:
> please ignore my previous post
>
> this one should work :-)
>
>  svn status
> M      src/storage/entities.xsl
> M      src/storage/README
> D      src/storage/akonadi-storage.xmi
> A      src/storage/akonadidb.xsd
> M      src/storage/dbinitializer.cpp
> M      src/storage/akonadidb.xml

ok, this contains already part of my changes, so please commit.

regards
Volker

> Am Samstag, 26. Mai 2007 21:02 schrieb Christian Schaarschmidt:
> > Am Donnerstag, 24. Mai 2007 11:20 schrieb Volker Krause:
> > > On Wednesday 23 May 2007 21:05:33 Christian Schaarschmidt wrote:
> > > > Am Montag, 21. Mai 2007 18:00 schrieb Volker Krause:
> > > > > On Friday 18 May 2007 19:38:36 Christian Schaarschmidt wrote:
> >
> > [...]
> >
> > > > - MimeType : Location relationShip
> > > >   does it indicate currently stored or possible to store mime types?
> > >
> > > the latter
> > >
> > > > - MimeType : PimItemPart relationship
> > > >   I guess that is needed for e.g. attached jpeg
> > >
> > > yes, although PimItemPart is not really implemented yet, see below.
> > >
> > > > - do we need to coordinate our meta data with Nepomuk project.
> > > > something like naming conventions, interfaces needed by nepomuk, what
> > > > is stored in Nepomuk DB what in akonadi server? is it possible to
> > > > share the metadata store ?
> > >
> > > Note that the ItemMetaData table has been dropped already. Meta data
> > > should be stored in nepomuk/strigi unless it's type-independent and
> > > absolutely necessary for eg. performance reasons to have them in
> > > Akonadi.
> >
> > I was not sure if it was just missing implementation or really removed.
> >
> > I have tried to put your answers into a patch. You might want to check
> > that before we commit it ;-)
> >
> > svn status
> > M      storage/entities.xsl
> > M      storage/README
> > D      storage/akonadi-storage.xmi
> > M      storage/akonadidb.xml
> >
> > > > - do you have a particular task in mind, I could start with? I'd like
> > > > to avoid conflicts in svn during commit ;-)
> > >
> > > Hm, some ideas are:
> > > - fully implement cache policies: we currently only have a very simple
> > > proof-of-concept implementation, so there are a lot of possibilities:
> > > client interface for manageing cache policies, add support for space
> > > limits, finish support for time limits (I think it's still too
> > > aggressive ;-) ), GUI elements for selecting/editing policies, ...
> > > - somewhat related: generic interval syncing per resource/collection
> > > - get the strigi/nepomuk feeders working again, they are quite old
> > > already and seem to need an update to the latest interfaces
> >
> > I think I'll try that first.  This looks like a good exercise before
> > looking into XESAM
> >
> > > - strigi recently got support for XESAM which is a freedesktop search
> > > spec including live searches. This will finally allow to implement
> > > persistent searches in Akonadi. Probably the most interesting task of
> > > these :) Other stuff that is needed on the server are item part support
> > > and conflict detection, but these are covered by Robert's master thesis
> > > already.
> >
> > Regards
> > Christian


-------------- 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/20070528/87a165b9/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/