[Bioc-devel] BrowserViz

The high-level type issue is sort of discussed here:

http://chimera.labs.oreilly.com/books/1230000000545/ch17.html#_subprotocol_negotiation

What about extending your protocol so that the payload consists of two
fields:
content-type and content, where the content-type adheres to the media type
specification? This is analogous to how every S4 object has a class
attribute.

Thanks for the discussion!

On Fri, Apr 3, 2015 at 2:57 PM, Paul Shannon <
paul.thurmond.shannon at gmail.com> wrote:

Hi Michael,

Thanks for the clarification.   You make a good point about caching:
nobody wants to have to reinvent and re-engineer that!   If too many
features like that become important, then the simplicity of websockets

will

have an attendant cost.

With regard to more formalism around the payload:  I can imagine that
there will be circumstances in which that is essential.  A
SummarizedExperiment browser would be very useful, and would clearly
benefit from a standard payload structure.

I figure, however, that that's above my pay-grade ;).   I leave that up

to

people like you.  And I stand ready to add any features such formalized
structures might require.  I'd like to think (I may be naive) that the
architects of SummarizedExperiment and heavy users of it could devise and
negotiate some standard JSON representation of the class, translators to
and from, which all could then be used by BrowserViz without BrowserViz
needing to know it's there.

The "binary JSON" format may be useful in some circumstances:
http://bjson.org

 - Paul

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

On Fri, Apr 3, 2015 at 2:00 PM, Paul Shannon <

paul.thurmond.shannon at gmail.com> wrote:

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.

I was just referring to potential complexity. If one attempted to

reimplement the useful features of HTTP (like caching), complexity would

be

introduced into application code, while you really want that complexity

in

the protocol implementation. HTTP seems most appropriate for when the
server is acting as the data model. Outside of that, I see the benefits

of

web sockets.

I think you missed my question about RPC. Also, any thoughts as to more

formalism around the payload? We obviously have complex data structures,
and it would be nice to communicate semantics somehow to the web browser.
For example, could there be some convention for representing a
SummarizedExperiment? Could a payload contain the equivalent of a media
type that an R/JS library could understand to marshal objects? Could

there

be some way to query for the types of payload a command supports?

I've seen stuff like WAMP, but they seem to lack the ability to declare

high-level types. Maybe that's just out of style?

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]]

        [[alternative HTML version deleted]]