[Xapian-discuss] Node.js binding

[Liam]

On Thu, Oct 20, 2011 at 3:21 PM, Richard Boulton <richard at tartarus.org>wrote:

> On 20 October 2011 21:17, Liam <xapian at networkimprov.net> wrote:
> > A mature Node binding would have both sync and async variants of the API,
> > and let the user choose based on his knowledge of the deployment context.
>
> Okay; but I don't entirely see what this has to do with whether
> Document::get_data() performs IO.
>

You said it may or may not block, depending on context. If the developer
knows the context, he can choose sync or async accordingly.

>
Really, we can't guarantee that any but the most simple API methods
> won't block, since that's not part of the Xapian API definitions at
> present, and therefore even if they don't block now, we might need to
> change them to perform blocking calls in some circumstances future
> releases.  Even the Query constructors could block, in theory, since
> there's one which takes a user-defined posting source as an argument,
> and calls that posting source's "clone()" method, which can do
> anything.
>

Well that's a user-defined source of blocking, right? The user can arrange
to set up the source before handing it to the Query.

>
> Concurrent calls to the same method of *different* objects cause
> problems??
>
> Not usually (though for example, a call to an Enquire object will
> often result in a call to a Database object inside Xapian, so this can
> be true).
>

Wouldn't the user know that the Enquire was bound to that Database instance?


>
> Node developers already have to deal with the implications of async I/O.
> > Simultaneous writes to a file can cause problems. Node avoids
> > multi-threading gotchas only in JS code. So yes, a Node developer would
> know
> > to use separate Database instances, or serialize access to a single one.
>
> Okay; then it sounds like the important thing is to document the need
> to serialize access to any Xapian objects and objects derived from
> them.  I worry that it's a little fragile, and overly easy to cause
> concurrent access by mistake, but I don't have enough Node experience
> to know whether that worry is valid, so will leave it up to you!
>

Surely you must have many users who allow concurrent connections to xapian
databases, so there's some standard way of isolating the connections'
activities?