On Tue, 2008-09-09 at 12:53 +0100, Øyvind Kolås wrote: > On Mon, Sep 08, 2008 at 12:18:54PM -0700, Jimmy Huang wrote: > > On Fri, 2008-09-05 at 12:23 +0100, Øyvind Kolås wrote: > > > On Wed, Sep 03, 2008 at 05:41:45PM -0700, Jimmy Huang wrote: > > > > I completed a design document draft of Content Manager for Moblin 2.0, > > > > which is part of the Application and Framework infrastructure. It is > > > > based on Meta Tracker (Trackerd) and SQLite. > > > > > > I agree, because applications need a way to not only query the extracted > > metadata, but also a way to store metadata that's application-specific. > > This is what tracker doesn't provide a lot, it does let user give a tag > > string to the file, but you can't really give labels to the information > > dynamically. > > Internally tracker is technically also RDF, since it stores its data as > triplets. But by not allowing extending the set of meta data stored it > limits some of the potential uses of it as a meta data store.
Just a thought, we modify tracker to create additional tables for creating an extensible metadata set and joins them when querying the database. Jimmy > > > > A plan > > > ====== > > > > > * snip * > > > > > > This development plan makes it possible to parallelize development and > > > avoid > > > having some branches of development depend on the others. > > > > It makes sense to do parallel development because Tracker is actively > > developed and constantly optimized. I think what's going to need to > > drive the metadata storage design is how are the applications intended > > to use it. > > The plan above is a possible course of action, my main concern about > tracker is that it is not flexible enough and that it might already be > doing quite a few things that we do not need. I am experimenting with > prototype shared core infrastructure for photo/video/music > management/browsing applications and I still do not know the extent of > APIs desired, but I do know that I would prefer to do queries and > travesals of the database in-process rather than proxy that over d-bus. In-process is always better, d-bus will always be constrainted and inefficent over a certain limit, but will be efficient if you fall within that range, I think it is 4kB. It is really up to the usage model and what kind of data is being queried. But it is nice to take this into consideration. Jimmy _______________________________________________ dev mailing list [email protected] https://www.moblin.org/mailman/listinfo/dev
