[Xapian-discuss] Node.js binding -- feedback wanted

[Olly Betts]

On Thu, Nov 10, 2011 at 03:22:49AM -0800, Liam wrote:
> On Thu, Nov 10, 2011 at 2:28 AM, James Aylett <james-xapian at tartarus.org>wrote:
> > Liam, the fact that you haven't had feedback suggests that no one else on
> > this list uses node.js.

I'm backlogged and haven't looked, but I doubt I could provide any useful
insights anyway, as I have no direct experience of node.js.

> > In previous cases of new bindings we've suggested reaching out to the
> > language (in this case platform) community to ask their advice.
> 
> Apologies for pestering you gentlemen. I hope you don't mind my prying as
> to which Xapian APIs cause I/O.

I don't think you're going to get a full answer to such questions,
beyond "most functions/methods might do I/O in some cases in the future
even if they don't currently".

The API currently doesn't document what can cause I/O, and I think we
don't want to tie our hands on the internal implementation by going
through and defining this exactly (I understand from what you've said
previously that the node API you would provide would be different in
the two cases, so changing the "can do I/O" status means incompatible
changes for your API).  Batching up updates and lazily reading data
both drastically improve performance in many cases, so restricting our
ability to do more of either isn't something we want to do.

As I said early on, I think we could sanely mark a subset of the API
as definitely not directly causing I/O.  Though of course doing pretty
much anything may result in the OS deciding to write/read data pages
to/from swap, or read code pages from program or library binaries (and
the latter can even cause network traffic if the binaries are on NFS!)

The sort of functions/methods I'm thinking we could reasonable mark in
this way are the version-related functions, get_description() methods,
etc.  We could actually document this by marking these methods/functions
in the API headers with a macro, so you could easily automatically pull
out such a list into a file, which would permit automated use (in the
Python bindings we don't need to release the GIL while calling methods
which don't do much work, which isn't exactly what you're interested in
but is pretty similar).

Cheers,
    Olly