Posting recent offline discussion... On Fri, Apr 27, 2012 at 10:55 AM, Marius Tibeica <mtibeica at gmail.com> wrote:> Hi Liam, > > I've added the Enquire class and designed a query spec structured as a JS > object. Hope you like it :) > I'll probably be off a few days (there is a national holiday Tuesday which > means i have a long weekend :D) but maybe I'll finish next week with the > design phase. > > Marius > > > On Thu, Apr 26, 2012 at 1:31 PM, Marius Tibeica <mtibeica at gmail.com>wrote: >Hi Liam,> > I have made the changes and added a few more classes: > https://raw.github.com/mtibeica/node-xapian/master/docs.md > > > On Wed, Apr 25, 2012 at 11:48 AM, Liam Breck <networkimprov at gmail.com>wrote: > >> Hi, some thoughts... >> >> I think this dev plan could go in a different file than the readme. Maybe >> start a docs.md markdown file? >> >> Function names: internally i use V8StyleCamelCaseNames, but I surface >> underscored_names to Javascript to follow the Xapian style. So if this text >> is intended to be a docs draft, switch to the latter. >> >> Argument names: to indicate expected type in docs, prefix with the V8 >> type names & underscore: >> string_n object_n array_n int32_n uint32_n function_n external_n >> boolean_n >> >> Similarly with result objects: { name:v8type } >> >> (I generally use iArg, oArg, ioArg to indicate whether the arg is input, >> output, or both, but since JS functions get a single Arguments object, I >> abandoned that in this binding.) >> >> Should the list-iterator functions take optional start & end arguments to >> allow the user to limit the range? >> >> The Xapian query-builder functions are useful because the C++ compiler >> will validate user's query syntax. In JS we don't have a compiler, so an >> object-based query spec is easier to use, IMO. >> >> >> On Wed, Apr 25, 2012 at 6:35 AM, Marius Tibeica <mtibeica at gmail.com>wrote: >> >>> Hi Liam, >>> >>> I have made a draft for the Database class - >>> https://github.com/mtibeica/node-xapian/blob/master/README.txt >>> Let me know if you think it's ok and I will continue with the rest. >>> I have only added the Sync version, as the Async is pretty similar >>> (callback with the return value instead of returning) >>> >>> As for the query, I was thinking about implementing most of the methods >>> similar to the way they are in C++ (for people who already use xapian) and >>> afterwards add helping methods. >>> >>> Marius >>> >>> >>> On Tue, Apr 24, 2012 at 9:00 PM, Liam Breck <networkimprov at gmail.com>wrote: >>> >>>> Congrats Marius! Welcome aboard. >>>> >>>> Writing up a draft for the APIs you'll be tackling sounds good. You can >>>> post it in your github fork as you work on it, and I'll comment there as >>>> you go. Watch for where you can combine API features into a higher-level >>>> function, as I did with Enquire::GetMset(). Doing sync & async versions of >>>> many APIs makes sense. Node does this for the require('fs') module; see >>>> node-v.../src/node_file.cc >>>> >>>> We might want to design a query spec structured as a JS object, instead >>>> of surfacing all the different query functions. For example: >>>> >>>> (one OR two) AND green ==> {op:AND, terms:[ {op:OR, terms:['one' , >>>> 'two']} , 'green' ]} >>>> >>>> Olly, you mentioned that you're moving to the MIT license, but I only >>>> see GPL in the github repo. There are multiple MIT licenses. Perhaps this >>>> one? http://xfree86.org/current/LICENSE4.html >>>> >>>> Liam >>>> >>>> >>>> On Tue, Apr 24, 2012 at 3:31 AM, Marius Tibeica <mtibeica at gmail.com>wrote: >>>> >>>>> Hi Liam, >>>>> >>>>> I saw that I was chosen for GSoC and started my work by looking for >>>>> ways in which Xapian is used. >>>>> >>>>> At http://oligarchy.co.uk/xapian/1.2.9/Search-Xapian-1.2.9.0.tar.gz(the Xapian Perl binding) there are unit tests and simple and advanced >>>>> query and indexing methods. >>>>> I will look for others and then create a draft of the nodejs >>>>> interfaces of all the methods, if that is ok with you. >>>>> >>>>> The one thing that I don't really know is how to decide which methods >>>>> should be sync and which async. >>>>> While I had the irc interview the idea that the other xapian members >>>>> liked the most was to implement both and explain in the documentation why >>>>> one should be used over the other, especially since things can change over >>>>> time. This isn't quite the node way but I think it is an acceptable >>>>> compromise. >>>>> >>>>> Marius >>>>> >>>>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20120427/896df0de/attachment-0001.html>
Posting recent offline discussion... On Fri, Apr 27, 2012 at 10:55 AM, Marius Tibeica <mtibeica at gmail.com> wrote:> Hi Liam, > > I've added the Enquire class and designed a query spec structured as a JS > object. Hope you like it :) > I'll probably be off a few days (there is a > national holiday Tuesday which means i have a long weekend :D) but maybe > I'll finish next week with the design phase. > > Marius > > > > On Thu, Apr 26, 2012 at 1:31 PM, Marius Tibeica <mtibeica at gmail.com>wrote: >Hi Liam,> > I have made the changes and added a few more classes: > https://raw.github.com/mtibeica/node-xapian/master/docs.md > > > > On Wed, Apr 25, 2012 at 11:48 AM, Liam Breck <networkimprov at gmail.com>wrote: > >> Hi, some thoughts... >> >> I think this dev plan could go in a different file than the readme. Maybe >> start a docs.md markdown file? >> >> Function names: internally i use V8StyleCamelCaseNames, but I surface >> underscored_names to Javascript to follow the Xapian style. So if this text >> is intended to be a docs draft, switch to the latter. >> >> Argument names: to indicate expected type in docs, prefix with the V8 >> type names & underscore: >> string_n object_n array_n int32_n uint32_n function_n external_n >> boolean_n >> >> Similarly with result objects: { name:v8type } >> >> (I generally use iArg, oArg, ioArg to indicate whether the arg is input, >> output, or both, but since JS functions get a single Arguments object, I >> abandoned that in this binding.) >> >> Should the list-iterator functions take optional start & end arguments to >> allow the user to limit the range? >> >> The Xapian query-builder functions are useful because the C++ compiler >> will validate user's query syntax. In JS we don't have a compiler, so an >> object-based query spec is easier to use, IMO. >> >> >> On Wed, Apr 25, 2012 at 6:35 AM, Marius Tibeica <mtibeica at gmail.com>wrote: >> >>> Hi Liam, >>> >>> I have made a draft for the Database class - >>> https://github.com/mtibeica/node-xapian/blob/master/README.txt >>> Let me know if you think it's ok and I will continue with the rest. >>> I have only added the Sync version, as the Async is pretty similar >>> (callback with the return value instead of returning) >>> >>> As for the query, I was thinking about implementing most of the methods >>> similar to the way they are in C++ (for people who already use xapian) and >>> afterwards add helping methods. >>> >>> Marius >>> >>> >>> On Tue, Apr 24, 2012 at 9:00 PM, Liam Breck <networkimprov at gmail.com>wrote: >>> >>>> Congrats Marius! Welcome aboard. >>>> >>>> Writing up a draft for the APIs you'll be tackling sounds good. You can >>>> post it in your github fork as you work on it, and I'll comment there as >>>> you go. Watch for where you can combine API features into a higher-level >>>> function, as I did with Enquire::GetMset(). Doing sync & async versions of >>>> many APIs makes sense. Node does this for the require('fs') module; see >>>> node-v.../src/node_file.cc >>>> >>>> We might want to design a query spec structured as a JS object, instead >>>> of surfacing all the different query functions. For example: >>>> >>>> (one OR two) AND green ==> {op:AND, terms:[ {op:OR, terms:['one' , >>>> 'two']} , 'green' ]} >>>> >>>> Olly, you mentioned that you're moving to the MIT license, but I only >>>> see GPL in the github repo. There are multiple MIT licenses. Perhaps this >>>> one? http://xfree86.org/current/LICENSE4.html >>>> >>>> Liam >>>> >>>> >>>> On Tue, Apr 24, 2012 at 3:31 AM, Marius Tibeica <mtibeica at gmail.com>wrote: >>>> >>>>> Hi Liam, >>>>> >>>>> I saw that I was chosen for GSoC and started my work by looking for >>>>> ways in which Xapian is used. >>>>> >>>>> At http://oligarchy.co.uk/xapian/1.2.9/Search-Xapian-1.2.9.0.tar.gz(the Xapian Perl binding) there are unit tests and simple and advanced >>>>> query and indexing methods. >>>>> I will look for others and then create a draft of the nodejs >>>>> interfaces of all the methods, if that is ok with you. >>>>> >>>>> The one thing that I don't really know is how to decide which methods >>>>> should be sync and which async. >>>>> While I had the irc interview the idea that the other xapian members >>>>> liked the most was to implement both and explain in the documentation why >>>>> one should be used over the other, especially since things can change over >>>>> time. This isn't quite the node way but I think it is an acceptable >>>>> compromise. >>>>> >>>>> Marius >>>>> >>>>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20120427/f821c192/attachment.html>
List Admin: this list really needs a reply-to header, to prevent accidental off-list replies! On Wed, May 2, 2012 at 12:32 PM, Marius Tibeica <mtibeica at gmail.com> wrote:> On Wed, May 2, 2012 at 9:36 PM, Liam <xapian at networkimprov.net> wrote: > >> >> >> On Wed, May 2, 2012 at 6:32 AM, Marius Tibeica <mtibeica at gmail.com>wrote: >> >>> Finished the design of the sync methods: >>> https://github.com/mtibeica/node-xapian/blob/master/docs.md >>> I will probably continue with the creation of a test framework and >>> porting the tests from the Perl binding. >>> >> >> 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_* >> > > Is is possible to set multiple sort types with Enquire? The method names > seem to suggest otherwise to me. > We could do a set_sort with an array of objects like { by: 'relevance' }, > { by: 'value', sort_key: uint32, reverse: 'bool'}, and if a succession of > these objects is not supported (more than 2 elements, etc), to throw a not > yet supported exception. >I think an Enquire parameters object could include collapse-key, docid-order, cutoff, value, and a relevance field which can be: 0 or undefined - value ? set_sort_by_value : noop 1 - value ? set_sort_by_relevance_then_value : set_sort_by_relevance 2 - value ? set_sort_by_value_then_relevance : set_sort_by_relevance Also for testing, we'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... >> >> 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 "getting started" app, which I'll add to > my todo list. >Yes, you need unit tests ported from Perl, for sure. The Node app is to test the whole system, evaluate performance, etc Liam -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20120502/472e4973/attachment.htm>
James Aylett
2012-May-05 13:47 UTC
[Xapian-devel] List configuration (was re GSoC xapian node binding)
On 2 May 2012, at 21:14, Liam <xapian at networkimprov.net> wrote:> List Admin: this list really needs a reply-to header, to prevent accidental off-list replies!There are sufficient email clients that will use reply-to without prompting, causing accidental on-list replies (potentially far more damaging and embarrassing!) that I'm opposed to doing this. That's ignoring the 'traditional' arguments against reply-to for lists (which aren't terribly strong these days). (Some email clients have dedicated commands and functionality for mailing lists. Sadly most don't, leaving us in a least of multiple evils situation.) J
About the changes of Emit for node 0.6 0.6 - We need a .js wrapper to extent the prototype of the objects which emit events 0.4 - The prototype of EventEmitter is inherited in C++ : t->Inherit(EventEmitter::constructor_template); possible fix - we could just only include the C++ inherit on node 0.4 with a define and the js prototype only on node 0.6+ 0.6 - C++ emitting objects are derived from ObjectWrap 0.4 - C++ emitting objects are derived from EventEmitter possible fix - class XapWrapEe<T> : public ObjectWrap on node 0.6+ and XapWrapEe<T> : public EventEmitter on node 0.4 0.6 - C++ must get the "emit" function and then call it 0.4 - C++ just calls Emit possible fix - make XapWrapEe have an emit method which will be different for the different node versions Since we only have one emit in the existing binding, we decided to change that to a callback as events are not necessarily required, so these changes are not required yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20120607/5c83d12d/attachment-0001.html>