2007/5/21, jamie <[EMAIL PROTECTED]>:
On Mon, 2007-05-21 at 21:43 +0200, Mikkel Kamstrup Erlandsen wrote: > > > > > > 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 > > I just had seconds thoughts on this. One thing is that the spawning of > the Search object on the server doesn't touch the bus, but what about > when the client sets up a proxy to it? > > The current way where only handles are used is guaranteed to not have > extra dbus roundtrips and I really think this is an important > feature. > well we can - we only need a unique Id for the session so its one round trip max. For each new query we can append queryX where X is an incrementing integer to the session object path so no round trip is needed
This imposes additional tasks for the client. Although this could possibly be hidden in the toolkit bindings I still think it is a bit inelegant... Anyway it doesn't save a roundtrip in the current API. The NewSearch call takes a query_xml that you need to pass over the bus somewhere no matter what... About the bus round trip; I was worried that creating the proxy search object for the search would require a dbus round trip, are anyone certain about this?
Maybe we wont handle 100's of searches, but I could easily imagine > myself doing 50 searches/sec or whatever the engine could pull off. > This could fx be in a scenario where I would like to extract > meta-information about the index. Such as information clusters. can easily reuse existing search query objects for that - no need to keep creating new ones?
You can reuse the Session objects, but the Search objects are created for a specific query. A Search is to be considered a server-side compiled representation of a query. Cheers, Mikkel
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
