don't jsonify lang nodes

[gordonwoodhull]

Since I think I'm the only one who uses lang sexprs from rserve.js, I think it is safe to change the behavior.

I did something very hacky and short-term in the processing of lang nodes when I started working on RCloud more than two years ago (7085b9d0c962bc5af22fec292eb512cd64c58326): https://github.com/att/rserve-js/blob/develop/src/robj.js#L87-L91

I freely admit, I didn't know what I was doing and I just wanted to get something working. Before this, lang nodes were just disabled and would throw an exception.

Even though the complete sexprs are really verbose and difficult to work with, the current approach is broken because, among other things, it can't distinguish between strings and symbols.

What would be even better than changing the processing, and what @cscheid said was the original intent, would be to allow js-ocaps to specify what level of detail they want. I'm not sure how to do that, but if we figured that out, this could be a backward-compatible change.

Right now Rserve.wrap_all_ocaps replaces the value with its "jsonified" version here: https://github.com/att/rserve-js/blob/develop/src/rserve.js#L386

[cscheid]

Take into account that I now reply email from an .edu account, and so my brain is now 98.73% useless for technical activities :)

But if I recall correctly, what I meant by "allowing js-ocaps to specify what level of detail they want" was that instead of using wrap_all_ocaps for everything, we'd go for a more piecemeal approach, where wrap_ocap (is that the name for the individual function?) is the generic function that wraps everything, but whenever a particular ocap requires a more careful conversion procedure, we design and write that one instead.

because in a way, wrap_ocap takes a function and returns another function. But you could write a "wrap_ocap_but_not_lang" function, which you'd use to wrap the ocaps that need special treatment.

Does that make any kind of sense?

[gordonwoodhull]

Almost. :wink:

wrap_all_ocaps is the function that recursively replaces all ocaps with functions; wrap_ocap replaces a single ocap.

wrap_all_ocaps is called directly from onmessage before forwarding the message to its client (RCloud), and onmessage doesn't even seem to know about the individual js-ocaps. So right now we could perhaps customize at the RCloud level, but I don't think we could have individual js-ocaps decide what level of processing they want.

Unless perhaps they told RCloud what they want, and then rcloud.js chose the appropriate wrapper. Hmm. I guess it begs the question of how RCloud extensions would specify what they want in the code that gets eval'd by install_js.

Better stop staring at this and get back to "real" work...