The battle for the Client-side
[ A bit of TWIP's technical side, behind the scene ]
TWIP is going to be more than just a bunch of collaborative apps. It will also be the protocol behind those apps, that we plan to make available to other developers as well. So we started thinking about how we could make this protocol compatible with as many technologies as possible.
Java is what we’re working on right now. Dot Net is not too far. But then we thought: let’s make the TWIP protocol available for JavaScript and GWT. The GWT/JS trend is taking over the client-sided Internet one day at the time, so why not make a TWIP API for it? And it can be done…
… but there is a catch.
JavaScript can’t work with sockets. It can only work with (XML) requests. JS can’t keep a connection open and wait for the server to send incoming messages from other users. Rather, the client must periodically send requests for updates and wait for the server to provide them. Although this isn’t a major drawback, it is a inconvenience, since any protocol working exclusively with request isn’t exactly real-time. And this is one of the reasons Google Docs and other collaborative platforms out there have trouble with guaranteeing true synchronization.
So here’s the deal… First, the TWIP API will be Java – that’s for sure. Next we’ll consider writing a Dot Net API. And last, but must definitely not least – GWT and JavaScript – with the XMLRequest-oriented protocol. What we aim for is making these APIs interoperable with the TWIP server, so third-party developers can easily develop their collaborative apps in whatever fashion they see fit. We’ll leave it up to them to decide if on the client-side they go for the robust connection-oriented approach (in Java, JavaFX or Dot Net) or for the light-weight, flexible XML request based approach (in JavaScript and GWT).
So what do you think ?
Tags: api, dot net, gwt, java, java script, request, sockets, xml
You can comment below, or link to this permanent URL from your own site.
March 10, 2009 at 6:20 pm
I think TWIP is getting more and more interesting as time passes by and as I read these blog posts.
Although, I think you will end up like Steve Balmer shouting for developers.
March 10, 2009 at 11:10 pm
Don’t worry, we won’t just be developing a protocol and wait for other people to develop their apps using it. We’ll develop our own apps, but in designing the architecture of TWIP, we want to keep as many doors opens. The key to the success of TWIP is to view it not only as a service or product, but as a concept which could fit as many use cases as possible.
The point is to put almost no strain on third-party developers regarding the platform they should use or the serialization mechanism they prefer. Maybe some people like Dot Net more than Java, or binary more than XML. Who are we to say which one is overall better ?
April 17, 2009 at 11:32 am
First of all I would implement the APIs for JAVA and then the ones for GWT. At last, but not least, I would implement the .net APIs.
But why would you need dot net if you have java? From my point of view, they are both cover the same goal except .net is micro$oft proprietary and java is open-source. What about a python API?
[quote]
… but there is a catch.
[/quote]
Unfortunately our (RIA developers) ideas are limited to these boxes called browsers… Or not?!
What about a new browser supporting javascript socket connections?
May 14, 2009 at 7:12 am
Hi,
you sa here:
“JavaScript can’t work with sockets. It can only work with (XML) requests. JS can’t keep a connection open and wait for the server to send incoming messages from other users. Rather, the client must periodically send requests for updates and wait for the server to provide them.”
let me tell you one thing: JS CAN keep a connection open and wait for the server to send incoming messages from other users.
check my game here: http://www.e-forum.ro:8080/dynagame/index which proves this point. the technical explanation you will find on my blog here:
http://bash.editia.info/javascript-bomberman-javascript-multiplayer-24.php.
in short, i am using continuations from jetty, that frees my server app from having 1 thread per opened socket. and when an event on the server side appears the message is put on the response and returned to the waiting client browser, that fires a new request after getting the response.
May 14, 2009 at 11:12 pm
Hi jgabios,
There are indeed solutions to allow JavaScript to work with sockets. But not directly. Not by a JavaScript library. Since there are a great number of JavaScript programmers that like their way of doing things, Eclipse came with Jetty, Mozzila brought Rhino.
Also, you can use a Flash script and integrate it with JavaScript, or you can use servlets too (since you already mentioned Jetty).
JavaScript was first built as a validation language, to allow input controls checking. We believe that JS has still some performance hits, both regarding clientSide and serverSide. But hey, we haven’t seen all of it.
We appreciate your feedback and also congrats for your JavaScript game.
… Just as a thought, we are looking for means to write collaborative apps in any language, although the serverSide will be completely written in Java.
Our drawback is data model processing. For instance, we need to specify that the ‘blur’ operation should be applied identical to applications written in different languages. This forces the JavaScript programmer, who wants to write a collaborative app, to write code that should be executed on the Java server (as the server stores a centralized version of the model) .
May 15, 2009 at 12:36 pm
yes, js does not work directly with sockets [html5 has websocket notion, but that is the future]. but you can work well by pointing XHR web requests to your server , just make a serversocket listen on 80, and you can talk to a js app.
the communication will be done by these requests/responses and they are good enough in my opinion.
anyway, i am interested in what you are doing, maybe i will visit you for a java position – i hear you are hiring.