On Fri, 2010-03-19 at 15:25 +0000, Martyn Russell wrote: > On 19/03/10 13:56, Bastien Nocera wrote: > > On Fri, 2010-03-19 at 13:36 +0000, Martyn Russell wrote: > >> On 19/03/10 12:59, Bastien Nocera wrote: > >>> On Sun, 2010-02-21 at 18:12 +0200, Zeeshan Ali wrote: > >>> > >>> 2 things come to mind: > >>> - Tracker shouldn't need to use D-Bus to access its database read-only: > >>> https://bugzilla.gnome.org/show_bug.cgi?id=613255 > >> > >> Well, D-Bus provides a single entry point for any requests to the data. > >> If we then provide some direct access using a library, that complicates > >> things further. At this point we are not threaded, however, we are > >> currently looking into the possibility of doing this due to recent events. > >> > >> What is so bad about using D-Bus? > > > > See the original mail. It's pushing data over D-Bus that already went > > through the bus in a different form. > > > >> What is the relevance of read-only? > > > > I don't understand the question, or how it relates to the point I was > > making. > > What I mean is, what difference does it make if the data is readonly or > readwrite?
I'm mentioning read-only because I believe it would be possible to implement with your current architecture. If you want read/write access, it would probably involve file locking, and all sort of nastiness that I understand might be problematic. Reading the data through a native API instead of through D-Bus would mean being able to shift very large amounts of data without the marshalling/demarshalling (say, loading 100k audio tracks' metadata would probably take a large amount of time over D-Bus, where it would be of negligeable duration through a more direct API). > Surely applications would want ONE method not two for > communicating with Tracker's. Or did I misunderstand somehow? This would all be hidden behind the tracker libraries for most developers, so it shouldn't matter. You'd get the same result, just much faster. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
