Re: [Tracker] Simplifying DBus interface

[Laurent Aguerreche <laurent aguerreche free fr>]

Le lundi 11 septembre 2006 Ã 15:37 -0400, Samuel Cormier-Iijima a
Ãcrit :
> I don't think we need to hide how the database is structured
> internally - we're talking about open source here anyways :-), and
> somebody can just access the database directly.

It is not a problem with open-source but with encapsulation, with good
programming practices... What happen if someday an update is required in
the DB structure? An update for performances or to add features? You
will ask each clients of trackerd to update its internals (and if they
made complicated SQL queries, they will be very happy to update
them :-D )?!

If we let clients to directly query DB, we open many ways to access DB
and some unforeseen ones.

IMHO a direct access to DB is a really bad idea.


>  Actually, I was
> talking with thiago on #dbus and he had this to say:
>
> thiago: I mean, there's nothing wrong in developing a backend for a
> service that uses D-Bus to talk to a daemon
> thiago: I just wonder why people develop new libraries doing that
> instead of simply developing the daemon and the API
> yoshiznit123: just for simplicity, as you said vanilla dbus is pretty difficult
> thiago: right, but the XML is much simpler
> yoshiznit123: xml? we have the introspection file if that's what you mean...
> thiago: yep
> thiago: if your library is just a thin-wrapper around the XML, I see
> no need for the library
> thiago: if it does something more involved, then it makes sense.
> yoshiznit123: yea, i think we have a wrapper around the header created
> by dbus-binding-tool
> yoshiznit123: :-)
> thiago: that's my point: if we can recreate your library using a code
> generator, then we don't need a library :-)
> yoshiznit123: yea, i'll point that out to jamie
> thiago: IMO, it makes sense to have a library when D-Bus is just one
> of many (possible) backends
> thiago: for instance, libtracker could open the SQLite database
> directly and avoid the daemon
> thiago: in that case, it makes sense to have a library
>
> Would it be better to extend libtracker to allow direct mysql queries
> (bypass dbus completely)? i thought that would have a few problems,
> such as database locking and pulling in libmysqlclient or sqlite as a
> dependency on libtracker, and i'm not sure it would provide many
> advantages... the reason is because dbus wouldn't be able to handle
> queries sent over dbus with really big result sets...
>
> anyways, it's jamie's call :-)
>
> samuel
>
> On 9/11/06, Laurent Aguerreche <laurent aguerreche free fr> wrote:
> > Le lundi 11 septembre 2006 Ã 19:38 +0100, Jamie McCracken a Ãcrit :
> > > > The idea i had was that we could provide frontend libraries (python ,
> > > > c, etc) that build the right SQL queries client side, and send it
> > > > through one DBus function, instead of multiple DBus functions that
> > > > build queries server side; however, i'm not sure it would add any
> > > > advantages except for the simpler DBus interface, and could very well
> > > > be harder to code (since we'd have to write sql building code for
> > > > languages we need to support).
> > >
> > > Almost all of the methods call a Stored procedure and do not build up
> > > queries. SPs are way faster than building queries because they are
> > > already compiled and optimised to bytecode and need no parsing like sql.
> > >
> > > The only benefit would be to allow querying of stuff not supported by
> > > the dbus interfaces. (still handy to have mind you)
> >
> > But you'll have to ensure that all queries won't "corrupt" DB and you
> > will expose how DB is architected internally...
> >
> >
> > Laurent.