Re: [Tracker] Database access abstraction

[Jürg Billeter <j bitron ch>]

On Mon, 2008-11-03 at 09:12 -0500, Jamie McCracken wrote:
> On Mon, 2008-11-03 at 12:46 +0100, JÃrg Billeter wrote:
> > On Sat, 2008-11-01 at 01:11 +0000, Martyn Russell wrote:
>
> > > - tracker_data_query_check_service(), I would probably call that
> > > tracker_data_query_file_exists(). We have this concept of "service"
> > > meaning a file and I really dislike that, but I can understand why we
> > > have a generic word to describe data. For this API, it is specific to
> > > files so I think it would be fine to use "file" instead of "service".
> >
> > Can't this function also be used e.g. with emails? Then maybe call the
> > function tracker_data_query_service_exists?
> >
> > I also dislike the confusion between service, service type, and file,
> > it's really used inconsistently. I'd just consistently use RDF
> > terminology to make it easier to understand, but I don't know how other
> > people would feel about a terminology change, Jamie? In RDF terminology,
> > we'd have resources (services/entities), classes (service types), and
> > properties (metadata fields).
>
> only file specific operations should use the name "file"
>
> generic ones should use service name so i agree with Juerg here
>
> you can rename Service to ServiceClass or ServiceType if you like

Ok, using ServiceType everywhere instead of Service where it doesn't
mean a single entity should certainly already help. In my opinion,
Resource and Class would be even better names for Service and
ServiceType, respectively. It would also make it immediately
understandable to anyone familiar with RDF. I don't know whether that's
a too radical change, though.

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?

JÃrg