Re: Module Proposal: Rygel



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]