[XESAM] Last Changes Before RC1 (sorry for delay)

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Sat Sep 29 14:07:32 PDT 2007


2007/9/28, Arun Raghavan <arunisgod at gmail.com>:
>
> Hello,
> Sorry about the delated response.
>
> On 9/26/07, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> > This will be the last batch of changes before we call RC1 (modulo
> upcoming
> > ontology update). As usual you can find the proposed items on
> > http://wiki.freedesktop.org/wiki/XesamSearchUpdates. There
> > are some pretty central items in there. Highlights include:
> >
> >  * Error/Exception handling
> >   * GetHits/GetHitData return type
>
> Just to have this explicit, the only way the server is going to know
> what type to return for a given field is is to know the whole metadata
> spec, right? Do we need to account for that fact that the server might
> not even know what the expected type for a field is?


Yes, as it stands, the server has to know the entire ontology to be able to
know the correct types to return.

The server should always be able to know the types for each field since
custom extensions should also have their ontologies properly installed in a
place where the server can pick them up.

If I am not mistaken Jamie has been requesting that it should always be
allowed to return a string instead of the actual data type (and let the
client do the conversion as it sees fit). I'm not sure where I stand on
this. It should not be hard to wrap nicely in a client lib anyway. My plan
was for xesam-glib to have a hit api like:

Hit.get_string(String fieldname)
.get_integer ()
.get_boolean ()
.get_date ()

- and use the g_valu_transform API to do type mappings as necessary. This
way it will not matter much where the type-detection logic is (for users of
xesam-glib).

Any opinions are mostly welcome. While this subject has seen quite some
debate on IRC, it can certainly always use more, it is quite central to the
spec.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070929/df06de93/attachment.html 


More information about the xdg mailing list