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.shan...@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.mich...@gene.com> > wrote: > > > > > > > On Fri, Apr 3, 2015 at 2:00 PM, Paul Shannon < > paul.thurmond.shan...@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.mich...@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@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > > > > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
