Comments on: The battle for the Client-side http://9thprime.wordpress.com/2009/03/10/the-twip-client-side/ [ Starting up a blog ] or [ Blogging a start-up ] Fri, 11 Sep 2009 08:46:48 +0000 http://wordpress.com/ hourly 1 By: jgabios http://9thprime.wordpress.com/2009/03/10/the-twip-client-side/#comment-47 jgabios Fri, 15 May 2009 12:36:51 +0000 http://9thprime.wordpress.com/?p=108#comment-47 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. 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.

]]> By: Cristian http://9thprime.wordpress.com/2009/03/10/the-twip-client-side/#comment-46 Cristian Thu, 14 May 2009 23:12:42 +0000 http://9thprime.wordpress.com/?p=108#comment-46 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) . 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) .

]]> By: jgabios http://9thprime.wordpress.com/2009/03/10/the-twip-client-side/#comment-45 jgabios Thu, 14 May 2009 07:12:20 +0000 http://9thprime.wordpress.com/?p=108#comment-45 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. 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.

]]> By: Cristian - Nicanor http://9thprime.wordpress.com/2009/03/10/the-twip-client-side/#comment-41 Cristian - Nicanor Fri, 17 Apr 2009 11:32:52 +0000 http://9thprime.wordpress.com/?p=108#comment-41 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? 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?

]]> By: Bogdan http://9thprime.wordpress.com/2009/03/10/the-twip-client-side/#comment-40 Bogdan Tue, 10 Mar 2009 23:10:45 +0000 http://9thprime.wordpress.com/?p=108#comment-40 Don't worry, we won't just be developing a protocol and <strong>wait </strong> 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 ? ;) 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 ? ;)

]]> By: Valentin http://9thprime.wordpress.com/2009/03/10/the-twip-client-side/#comment-39 Valentin Tue, 10 Mar 2009 18:20:23 +0000 http://9thprime.wordpress.com/?p=108#comment-39 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. :) 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. :)

]]>