On 2014-03-01 21:04, Michael Haberler wrote: > not for me - in fact I think it as reassuring to see we to converge on the > same concept: Web UI interaction will happen over Websockets, and with JSON > objects mapped to internal representation at the boundary; it is the approach > taken by Peter Jensen with rockhopper, and (minus websockets) also the > approach Sergey has taken in emcweb. Yes Michael, I know that you stick deep in this stuff. (slightly literally ;) As we discussed at our last/first real talk, JSON is another buzzword for serializing objects. But its rusticity is smitting.
> The current implementation uses a Websockets proxy server based on > libwebsockets (http://libwebsockets.org/trac/libwebsockets). That is a > relatively low level bridge, but it is very fast, has a stable API, and the > package is well supported by author and community. It also builds easily. So > it's a safe stopgap. Another candidate I would suggest is https://github.com/zaphoyd/websocketpp . Especially as interim solution for the next stable branches in terms of a "nml to websocket bridge/gateway". I think it's a easy task for jeff and/or axel. (I wasn't saying anything ;) > I see several interesting alternatives to libwebsockets/C: > > One would be to use node.js instead. There are several advantages to that, in > particular it makes it much easier to to server-side extensions (in > JavaScript instead of C), and many required bindings (zeroMQ, protobuf, > Websockets) are available stock for node.js . The reason why I am not using > node.js yet at this point in time is: this target still moves too fast. See below. > Another one would be to do the proxy in Go: also, all bindings available > stock, and very fast. It is another interpretive language, and a bit heavy to > require up front. It has significant potential for near-RT operation relative > to Python; it is still a garbage-collecting language and hence not hard-RT > capable. Yes, some reading matter for it: http://www.springer.com/computer/swe/book/978-3-642-29968-1 > The third stock option one would be twisted, and an-all Python proxy. > > I think it really boils down to quality and effort to build prerequisites. > But certainly there is room for experimentation and alternatives. Yes, just in case instead of just in time! Spreading the knowledge as the saying goes. (I think Seb has said it in the IRC...) > > In fact I would be very interested to cooperate with a person knowledgeable > in node.js for a prototype interface to what I already have. Any takers? Sorry my nodejs experiences are very low. Maybe in the next months if you are patient. ;) > > > - Michael > Matsche -- "In der Wissenschaft siegt nie eine neue Theorie, nur ihre Gegner sterben nach und nach" Max Planck ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
