[Bioc-devel] BrowserViz

[Michael Lawrence]

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]]
> >
> > _______________________________________________
> > Bioc-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>

	[[alternative HTML version deleted]]