2007/5/21, jamie &lt;<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>&gt;:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 2007-05-21 at 21:43 +0200, Mikkel Kamstrup Erlandsen wrote:<br><br>&gt;<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; 5) And a bigger issue, that is a tough call... Should we use<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; real dbus<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; objects for sessions/searches? According to Havoc Pennington
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; it<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; doesn&#39;t take a roundtrip to the bus to register a new<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; object, so<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; spawning lots of search objects shouldn&#39;t flood the bus (not<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &gt; object-registration requests at least).<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; yes the overhead is negligible - its not like an app is going<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; construct 100&#39;s of search objects all at once
<br>&gt;<br>&gt; I just had seconds thoughts on this. One thing is that the spawning of<br>&gt; the Search object on the server doesn&#39;t touch the bus, but what about<br>&gt; when the client sets up a proxy to it?<br>&gt;
<br>&gt; The current way where only handles are used is guaranteed to not have<br>&gt; extra dbus roundtrips and I really think this is an important<br>&gt; feature.<br>&gt;<br><br>well we can - we only need a unique Id for the session so its one round
<br>trip max. For each new query we can append queryX where X is an<br>incrementing integer to the session object path so no round trip is<br>needed</blockquote><div><br><br>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...
<br><br>Anyway it doesn&#39;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...<br><br>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?
<br></div><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; Maybe we wont handle 100&#39;s of searches, but I could easily imagine
<br>&gt; myself doing 50 searches/sec or whatever the engine could pull off.<br>&gt; This could fx be in a scenario where I would like to extract<br>&gt; meta-information about the index. Such as information clusters.<br>
<br>can easily reuse existing search query objects for that - no need to<br>keep creating new ones?</blockquote><div><br>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.
<br><br>Cheers,<br>Mikkel<br></div></div>