Re: [Tracker] Database access abstraction

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?


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