[Bioc-devel] BrowserViz

Hi Michael,

Great to get your response, comments and questions.  Answers attempted
below.

I think our overriding difference lies in our contrasting experience of
complexity.  I have come to see websockets as minimal, simple, fast and
flexible, whereas you see them quite differently.  I would like to
understand your views on this; I could be overlooking somce important and
maybe costly complicating features, perhaps because of my fondness for
other simplifying features.

More below...

I look forward to hearing back from you.

 - Paul

On Apr 3, 2015, at 1:45 PM, Michael Lawrence <lawrence.michael at gene.com>
wrote:

Thanks to Val's excellent newsletter, I've had my first glance at
BrowserViz. I'm glad to see something that is more flexible and low-level
than e.g. shiny.

I'm curious about the motivation behind web sockets. I guess any
application with an R-driven web UI actually has two UIs: the R console

and

the browser. But what if the R session is headless, or if there is no

need

for commands in R to affect the browser? Then the web socket layer brings
mostly unneeded complexity.

I see websockets (like TCP sockets) as musch simpler than HTTP.  No
headers,
no explicit server and explicit client (once the connection is open).
Could you explain the complexity you see?

An interesting comparison to BrowserViz is not
shiny but OpenCPU. It's purely HTTP-based and still manages to maintain
state (not sure how efficiently). I guess one advantage of web sockets is
that one can program imperatively instead of declaratively on the server,
i.e., the server can send a command to show a popup in response to some
event, instead of returning a "declaration" that the popup should be

shown.

Exactly!

So essentially web sockets are more natural for implementing server-side
controllers (think MVC), instead of just the data model, but man, it's a
shame to lose the features of HTTP.

I'll confess:  I set out to -shed- the features of HTTP.  Isn't it a
protocol designed for serving up web pages on demand?  Not for fast,
lighweight peer-to-peer communications?

Ultimately, I think we want web apps that are easy to develop and

maintain,

and run equally well from either a useR's session or a remote client
communicating to a dedicated, headless server. Is the generality of
websockets worth the complexity?

As an aside, it would seem relatively straight-forward to implement a
simple bi-directional RPC mechanism between R and JS using the standard
protocol (i.e., hide details like the callback). Does that sound

reasonable?

I was also a bit surprised about the need to copy/paste the JS

boilerplate.

Certainly there must be javascript frameworks with a more elegant

solution

to extensibility.

You are correct on this, and I only need to correct the vignette, written
many weeks ago.
I now provide "BrowserViz.jx", a simple Javascript module.  It is used by
both
BrowserVizDemo and RCyjs.  Sorry to have sent out an obsolete vignette.

      [[alternative HTML version deleted]]