Mon Jun 25 15:17:53 CEST 2012
On a bit of a tangent here, if the JS part of the VoiceBrowser consists of "external" code that is subject to constant change, then, well, you might be a bit out of luck. On the other hand, if this is all pre-defined stuff, you might want to consider just rewriting most of the VXML interpreter in erlang. We did something similar a while back, and it worked pretty remarkably well.
You tend to end up with a fairly small (and somewhat tightly controllable) set of core JS stuff that you can farm out to a NIF, or just leave as JS if you so choose...
That Tall Bald Indian Guy...
Blog | Twitter | Google+
On Jun 25, 2012, at 6:17 AM, Robert Virding wrote:
> Sorry, sent this locally first time:
> An alternative would be to use NIFs to try an emulate mutable data. You could not most likely not use the BEAM process heaps as destructive updates would seriously confuse the BEAM memory management. And if you start using NIFs then maybe it is better to connect to a "real" JS as is done in erlv8.
> It really depends on how you would like to use JS.
> ----- Original Message -----
>> On Thu, Jun 21, 2012 at 11:12:26AM -0400, Ingo Jaeckel wrote:
>> } In either case - Why? What is the application behind this?
>> At the moment I am working with VoiceXML which incorporates
>> Although they call a VoiceXML interpreter a "voice browser" if you
>> consider where it is typically used in the network it is a server
>> } What about https://github.com/beamjs/erlv8/ and
>> Yes, there are a couple bindings to external engines. Erlyjs was
>> taking the approach I would prefer, interpreting the ECMAscript on
>> the beam machine.
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions