List Admin: this list really needs a reply-to header, to prevent accidental off-list replies!<br><br><div class="gmail_quote">On Wed, May 2, 2012 at 12:32 PM, Marius Tibeica <span dir="ltr">&lt;<a href="mailto:mtibeica@gmail.com" target="_blank">mtibeica@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">On Wed, May 2, 2012 at 9:36 PM, Liam <span dir="ltr">&lt;<a href="mailto:xapian@networkimprov.net" target="_blank">xapian@networkimprov.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div class="gmail_quote"><div>On Wed, May 2, 2012 at 6:32 AM, Marius Tibeica <span dir="ltr">&lt;<a href="mailto:mtibeica@gmail.com" target="_blank">mtibeica@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



Finished the design of the sync methods: 
<a href="https://github.com/mtibeica/node-xapian/blob/master/docs.md" target="_blank">https://github.com/mtibeica/node-xapian/blob/master/docs.md</a><div>I will probably continue with the creation of a test framework and porting the tests from the Perl binding.<br>



</div></blockquote></div><div><br>Can you look for other places where we can combine multiple methods into a single one with an object argument, as with Query::Query? For instance Enquire::set_sort_* <br></div></div></blockquote>


<div><br></div></div><div>Is is possible to set multiple sort types with Enquire? The method names seem to suggest otherwise to me.</div><div>We could do a set_sort with an array of objects like {  by: &#39;relevance&#39; }, { by: &#39;value&#39;, sort_key: uint32, reverse: &#39;bool&#39;}, and if a succession of these objects is not supported (more than 2 elements, etc), to throw a not yet supported exception. </div>
</div></blockquote><div><br>I think an Enquire parameters object could include collapse-key, docid-order, cutoff, value, and a relevance field which can be:<br>  0 or undefined - value ? set_sort_by_value : noop<br>  1 - value ? set_sort_by_relevance_then_value : set_sort_by_relevance<br>
  2 - value ? set_sort_by_value_then_relevance : set_sort_by_relevance<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote">
<div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>Also for testing, we&#39;d benefit from a simple HTTP-fronted Node app to which a user can post documents and submit queries. We could pull an interesting corpus into that, e.g. Wikipedia...<br>
</div></div></blockquote></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div>

</div></div></blockquote></div><div>Sure, that sounds great, but for the code writing I think that specific unit tests with predictable answers are more useful to me. The HTTP-fronted Node app looks more like a great &quot;getting started&quot; app, which I&#39;ll add to my todo list.<br>
</div></div></blockquote><div><br>Yes, you need unit tests ported from Perl, for sure. The Node app is to test the whole system, evaluate performance, etc<br><br>Liam<br></div></div>