2007/9/28, Arun Raghavan <<a href="mailto:arunisgod@gmail.com">arunisgod@gmail.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hello, Sorry about the delated response. On 9/26/07, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> 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 > <a href="http://wiki.freedesktop.org/wiki/XesamSearchUpdates">http://wiki.freedesktop.org/wiki/XesamSearchUpdates</a>. 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?</blockquote><div> 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 </div> </div>