[Kde-pim] Akonadi datamodel questions

[Christian Schaarschmidt]

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



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: storage.diff.bz2
Type: application/x-bzip2
Size: 7373 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070527/9a9a063a/attachment.bin>
-------------- 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/