Re: [Tracker] Fixing private headers included from public headers

[Jamie McCracken <jamie mccrack googlemail com>]

Dunno if this is related to this or not, but were we going to allow
direct access for clients to the tracker db? (as we dont multithread
tracker-store it will get slower and less responsive as more clients use
it)

If so surely quite a lot will need to be in tracker-common or some other
public lib

On Thu, 2010-02-11 at 10:48 +0100, JÃrg Billeter wrote:
> On Thu, 2010-02-11 at 10:07 +0100, Martyn Russell wrote:
> > On 11/02/10 01:34, Martyn Russell wrote:
> > > It looks like we need to make these publicly installable for libraries
> > > like libtracker-extract, etc:
> > >
> > > tracker-dbus.h (for libtracker-miner)
> > > tracker-statement-list.h (for libtracker-extract)
> > > tracker-sparql-builder.h (referenced from tracker-statement-list.h)
> >
> > After further reflection, I realised that tracker-dbus.h is not included 
> > by any headers for libtracker-miner. So we could simply keep that in 
> > libtracker-common and put the other two headers into libtracker-client. 
> > The reason this would work is that libtracker-extract depends on 
> > libtracker-client for linking anyway and it seems a more logical place 
> > to put these modules.
>
> Moving tracker-sparql-builder.* to libtracker-client sounds good to me.
> However, tracker-statement-list.* mainly contains obsolete functions, we
> should avoid exposing this as part of the public API. The
> tracker_sparql_builder_object_unvalidated function from that file should
> be public but the rest should be private or better removed.
>
> JÃrg
>
> _______________________________________________
> tracker-list mailing list
> tracker-list gnome org
> http://mail.gnome.org/mailman/listinfo/tracker-list