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?
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. I agree with your points. I am not sure if G_IS_FILE() would actually work for us here, if so, that could be utilised. But ultimately you are right. >>> 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 >>> a URI >> 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 :) > > I don't think that this would improve the situation a lot compared to > just using URIs. As far as I can tell, we would have to store the hashes > as strings as reduction to 64 bit integer is probably not sensible due > to possible collisions (and also with 128 bit MD5 we'd have to think of > a way to handle collisions). And if we store IDs as strings, we lose the > performance benefit. Yea, it would have to be an integer not a string. Oh well, :) -- Regards, Martyn _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
