[Xapian-devel] GSoC xapian node binding
Liam
xapian at networkimprov.net
Fri Apr 27 22:37:05 BST 2012
Re the Query structure spec, looks good.
> A query structure can be defined as:
> A query consisting of a single term.
> {
> tname: string,
> wqf: uint32, //default 1
> pos: uint32 //default 0
> }
> A query consisting of two or more subqueries, opp-ed together.
> AND, OR, SYNONYM, NEAR and PHRASE can take any number of subqueries.
> Other operators take only the first two subqueries.
> {
> op: string,
> queries: [ object_querystructure1, ...]
> }
> A value range query on a document value.
> {
> op: string,
> slot: uint32,
> begin: string,
> end: string
> }
> A value comparison query on a document value.
> {
> op: string,
> slot: uint32,
> value: string,
> }
>
>
Does it accommodate these, if so can you note where?
Query (Query::op op_, Xapian::Query q, double parameter)
Query (Query::op op_, const std::string &left, const std::string &right)
On Fri, Apr 27, 2012 at 11:14 AM, Liam <xapian at networkimprov.net> wrote:
> 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/2758cc74/attachment-0001.htm>
More information about the Xapian-devel
mailing list