Re: [Tracker] Database access abstraction

[Jamie McCracken <jamie mccrack googlemail com>]

On Mon, 2008-11-10 at 16:48 +0100, JÃrg Billeter wrote:
> On Mon, 2008-11-10 at 15:20 +0000, Martyn Russell wrote:
> > Jamie McCracken wrote:
> > > On Mon, 2008-11-03 at 15:30 +0100, JÃrg Billeter wrote:
> > >
> > > > What is your opinion on my proposal to introduce a TrackerService (or
> > > > TrackerResource) class - similar to the GFile interface in GIO - and use
> > > > that throughout the API where we currently use path, uri, or service id?
> > >
> > > the big disadvantage of this is that we end up supporting and coding in
> > > more paths through the code and more SPs - not sure if its worth it
> > > especially as in a lot of cases we will be supporting both uri and ID
> > > params where we only ever use one
> >
> > True.
> >
> > We could actually just:
> >
> >   typedef GFile TrackerResource
> >
> > For now just to keep it something internal which can change. That way
> > APIs stay the same and we do operations on the resource (or GFile if we
> > explicitly know it is a GFile).
>
> I don't quite understand how this would help. Either we say it's always
> a valid GFile, then we could directly use GFile in the API, however,
> this might be problematic for e-mails and possibly other resource types.
> Or we say it doesn't have to be a valid GFile, and then we won't be able
> to use any g_file_* functionality, which means that we need our own
> interface/class TrackerResource. Am I missing something?

well tracker has to support virtual uri which is not necessarily
supported by GIO so use of GFile is not really practical.

Of course there are places where stuff is only file specific where use of gfile makes sense

jamie