lawrence.michael at gene.com
Sat Apr 4 00:11:28 CEST 2015
The high-level type issue is sort of discussed here:
What about extending your protocol so that the payload consists of two
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
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:
> - Paul
> On Apr 3, 2015, at 2:43 PM, Michael Lawrence <lawrence.michael at gene.com>
> > 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
> > 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>
> > > 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
> > > 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
> > > for commands in R to affect the browser? Then the web socket layer
> > > mostly unneeded complexity.
> > I see websockets (like TCP sockets) as musch simpler than HTTP. No
> > 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
> > > that one can program imperatively instead of declaratively on the
> > > 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
> > Exactly!
> > >
> > > So essentially web sockets are more natural for implementing
> > > controllers (think MVC), instead of just the data model, but man, it's
> > > 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
> > > 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
> > >
> > > I was also a bit surprised about the need to copy/paste the JS
> > > to extensibility.
> > You are correct on this, and I only need to correct the vignette,
> written many weeks ago.
> 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]]
More information about the Bioc-devel