[Xesam] Practical applicability issues

[Philip Van Hoof]

On Fri, 2008-06-20 at 01:57 +0530, Arun Raghavan wrote:

> This is definitely going to make the Beagle Xesam implementation
> messy. Since our ontology is not nearly as complex as what Xesam
> defines, We just store a simple mapping from supported Xesam (leaf)
> fields to Beagle fields. If struct support is mandatory, we will need
> to add additional information to remember what fields are actually
> structs or part of some struct, aggregate the fields we support, fill
> in the rest with default values, and then return them. Clearly
> non-trivial and messy.

The current Xesam implementation being made for Tracker does more or
less the same thing to map from native Tracker ontologies to Xesam ones.

We'd have similar problems and it would get equally messy to implement
this for Tracker.

> On a more general note, I (and I think I represent the sentiment in
> the Beagle camp here) feel that the spec is starting to deviate from
> its original goal, which AFAIK, was to have a standard way to talk to
> desktop search tools. I am not against the idea of being able to do
> more advanced stuff with the search spec, but the spec has to define
> some common minimum feature-set for servers to be able to meaningfully
> support Xesam and this bar seems to be getting raised significantly in
> this proposal.

I agree with this.


> IMO, one of the coolest things about the spec, and particularly the
> API and query languages, is the elegant simplicity. Somehow, this
> change seems to be undoing that simplicity to some extent.
> 
> Again, I do not want to imply that the spec should be constrained, but
> there should be some way in which the simplicity paradigm can be
> maintained in parallel with more advanced features/usage.

My proposal still stands to allow for an "extensions" namespace where
plugins and extensions can be built, and a small standard API to get a
list of available extensions (actually does DBus by itself provide this
with its reflection capabilities).

You'll always have servers that implement more than necessary for the
basic client. 

This would follow how protocols like POP (with CAPA) and IMAP (with
CAPABILITY) are extensible and advertise their capabilities this way.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be