Re: [Tracker] Database access abstraction

On Mon, 2008-11-10 at 15:59 +0000, Martyn Russell wrote:
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

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?

The idea was to keep the API the same but be able to interchange what
the resource represents if we need to at a later stage with a little
more ease.

its a nice idea but i prefer we did not do this as I said it would be a
lot more work/code/maintenance and much harder to optimize

AFAICT the only real overlap between indexing and user dbus api is
setting metadata (an api to allow indexing of virtual stuff via user
dbus will probably overlap a bit as well) so i dont think its worth it

if you can show significant overlap then i will reconsider


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