[Bioc-devel] BrowserViz

[Michael Lawrence]

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

	[[alternative HTML version deleted]]