[XESAM] changes in the Xesam XML Query Languae

[jamie]

On Mon, 2007-05-21 at 15:10 +0200, Mikkel Kamstrup Erlandsen wrote:
> 
> 
> 2007/5/21, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
>         2007/5/19, Jos van den Oever <jvdoever at gmail.com>:
>                 Hi all,
>                 
>                 I was rereading the xesam-query.xsd and have the
>                 following remarks about it.
>                 
>                 - There is no target namespace. This must be fixed
>                 before it becomes final.
>                 - The attribute 'type' on <query> is redundant since
>                 one also use a 
>                 selection for it.
>         
>         Why is the type attrib redundant? Fx searching for stuff of
>         type (or "category" in our current terminology) Document and
>         Xesam:Content.Creator=Jos needs it AFAI can see. 
>         
>         
>         The namespace should be fixed, that is certain. I believe the
>         wiki page also state that... It would just be nice to know if
>         we get those project pages on fdo or not before we settle on a
>         namespace.
>         
>         I have some other "diff"-proposals for the search spec
>         somewhere, I'll post them in a sec...
> 
> 
> Here are my proposed updates to the search spec (in addition to Jos'
> and Fabrice's):
> 
> 1) rename iface to org.freedesktop.xesam.Search (capitalize the last
> word "search") according to dbus interface naming conventions 
> 
> 2) spec out that client should take care to close their session
> objects, but that it it the servers responsibility to clear them up
> anyway. This can be done by logging caller name in NewSession and
> listening to NameOwnerChanged on org.freedesktop.DBus on
> old_name->empty string.

make sense

> 
> 3) Only allow UTF-8 XML in query language

of course

> 
> 4) There is no way to do the 'w' switch from user search language in
> xml query language. I propose to do this via a <string> attribute. 

whats w switch?

> 
> 5) And a bigger issue, that is a tough call... Should we use real dbus
> objects for sessions/searches? According to Havoc Pennington it
> doesn't take a roundtrip to the bus to register a new object, so
> spawning lots of search objects shouldn't flood the bus (not with
> object-registration requests at least). 

yes the overhead is negligible - its not like an app is going to
construct 100's of search objects all at once


We will be creating both a session object (one per client) and a search
object(s) so the search daemons can easily maintain them at the session
level