Re: [Tracker] Database access abstraction

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


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).

The indexing calls will all be ID based except for the call to check if
a file is up to date which is obviously URI driven and to get the ID for

I just had some crazy idea for a second there about perhaps having a
unique ID (like an MD5SUM) for each path which is the service ID in the
database (instead of auto incrementing it) - so you can always get the
ID easily without needing extra DB look ups. Am I on crack or is this
work investigating? Ignore me if it is :)

The dbus calls and user api will all be URi driven

URI or Path driven? right now they are all Path driven with the
exception of the thumbnail service which requires a URI. Long term I
would like to see URI support. The transition shouldn't be too hard.


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