[Xapian-devel] GSoC xapian node binding

[Liam]

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.htm>