suport for external JS libs in sync function

[ghost]

To support anything other than simple property mapping in the sync function it would be useful to be able to use external JS libs.

In TouchDB it's possible to add JS libs as properties of the design document, then they can be referenced in map and filter functions.

Ideally sync_gateway would support one of the JS module loader frameworks so that the require(module); operator may be called at the start of the sync function.

As a side note, most libs either expect a full browser runtime or a node.js runtime so will probably need adapting for sync_gateway use, but once ported these could be made available in a git repo.

[jchris]

I think we probably won't fix this, as the sync function code is meant to run in a vacuum. So you'll just end up having to copy and paste any relevant libraries inline to your javascript.

Maybe the "right" way to fix this would be to have an interface where the sync function runner can be an external program communicating via JSON and STDIO. That way you could replace the simple sync function runner with actual node.js or python or ruby or whatever.

Closing this ticket but totally happy to see it reopened if you disagree or see an easier solution.

[ghost]

Chris

Hi, I was really looking for better modularity where complex processing is required and external libs are available.

Once loaded I would fully expect them to be run in an isolated sandbox.

One thought, now that it is possible to define the sync function in an bootup config, maybe the inlining of external JS libs could be done at startup time, leaving the sync function as a static JS script at runtime.

Something like https://github.com/azer/onejs could be used?

I won't re-open the issue, if the majority of use cases for the sync function is for simple JSON property lookup then I can live with pasting all the JS into the bootup config file manually.

Andy

[snej]

My 2¢: It seems like sync functions don't have to be as pure as map functions, i.e. it isn't crucial that they are stateless and repeatable. I can't think of a reason why it would cause problems for one to invoke external code. (I think the same would apply to traditional CouchDB validation functions.) But you've been working with this sort of stuff longer, Chris?

[jchris]

The problem with non-isolated sync functions, is that if you change what a
document should map to ( channels access etc.) without actually touching
the document, then the access control rules will not be updated
accordingly. The access manager only considers documents as they are
touched.

I'm starting to think more and more that the right way for more complex
access management is to fall back on the model where are you have a daemon
listening to the full changes feed for the database and updating user
documents accordingly.

There is nothing you can do with the embedded sync function model that you
can't do with an external process.

On Wednesday, March 20, 2013, Jens Alfke wrote:

My 2¢: It seems like sync functions don't have to be as pure as map
functions, i.e. it isn't crucial that they are stateless and repeatable. I
can't think of a reason why it would cause problems for one to invoke
external code. (I think the same would apply to traditional CouchDB
validation functions.) But you've been working with this sort of stuff
longer, Chris?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-15183649
.

Chris Anderson
http://jchrisa.net
http://www.couchbase.com