On 30 May 2011 00:54, Adrian Cochrane <[email protected]> wrote: > With all this discussion on language/library, I'll definately stick to > my choice of psuedocode so as to cut through any "controversy". >
I'm not sure we can develop a c/s completely "blindly" to an implementation though - surely theres always going to be unexpected bugs and issues? Documentation can be done psudeocode on the site, but in order to work out exactly what to document I think we really need to make a working c/s connection. Seeing as that requires a wave server broadcasting out its messages, that means Java - at least for wiab. Client side, of course, doesn't matter so much as theres a lot more to test against and its vastly easier knocking up a new test client then a test wave server. > > On Mon, 30 May 2011 00:44 +0200, "Thomas Wrobel" <[email protected]> > wrote: >> As a gwt coder, that seems rather reinventing the wheel for no good >> reason. :) >> What gwt does for you is abstract away almost all browser differences >> leaving a very pure coding expirence to make webapps. >> "foo" most certainly isnt always the same when compiled because >> different browsers have both different javascript as well as layout >> engines. GWT gives you a generic "foo" for you to code in and compiles >> to different implementations per browser to give the end result as >> close to identical as possible, while ensuring no browser has to waste >> loading time on quirks for other browsers.(at the same time being very >> heavy at optimisation). So, by design, foo is not always a fixed >> thing. >> For what it does, gwt does very well, you'd be hard pressed to come up >> with a better replacement without a lot more manual work. >> >> In regards to widgets,layouts, and general web interface gwt is always >> going to unpredictable and changing at the html level. >> However, in regards to pure coding, its pretty stable. It could >> basicly just be seen as a subset of java. >> Specificaly this subset; >> http://code.google.com/webtoolkit/doc/1.6/RefJreEmulation.html >> (The biggest thing I've come accross personaly is just having to >> rememeber its Javascript style regexs) >> >> So porting to gwt is a problem if you use more then those, but porting >> away is never any work as its "just java". >> (I often reuse logic code between my gwt apps and my android stuff - >> as long as your not dealing with visual stuff theres rarely any >> issues) >> >> That said, I'm not saying its a great for a referance implementation, >> merely a way for all the code both sides to be done in Java if thats >> an advantage. >> >> At the end of the day I asume we are (probably) looking at a websocket >> based system anyway - possible sending messages done using an existing >> websocket implementation? So the question is over the code forming and >> packing what to send, as well as the code picking up the responses. >> The layout code doesnt play any role in this really. >> >> Its also quite possible to have a Javascript lib that a gwt app can >> interact with. (Or native javascript statements in gwt). Theres no >> reason why not to play to the strengths of various platforms. >> >> So you could have Java (Wiab server) >>>>(websocket)>>>>CS protocol >> Javascript lib>>>(generated javascript fropm gwt or something else) >> >> >> On 29 May 2011 23:12, Paul Thomas <[email protected]> wrote: >> > There was talk of getting rid of GWT a while back. I think it is useful >> > for Java >> > guys to prototype in, but it seems a bit of a monstrosity to me. There is >> > frameworks like sproutcore, and you can hand roll with coffescript. >> > >> > >> > >> > >> > >> > ________________________________ >> > From: Perry Smith <[email protected]> >> > To: [email protected] >> > Sent: Sun, 29 May, 2011 21:28:05 >> > Subject: Re: protocols >> > >> > >> > On May 29, 2011, at 3:10 PM, Thomas Wrobel wrote: >> > >> >>> >> >>> If the majority of the client side is going to actually use javascript, >> >>> then >> >>>lets use that on the client side. >> >>> >> >>> I wonder... can Rhino[1] hook in to another Java application? Then we >> >>> could >> >>>use javascript on both sides and still test. >> >> >> >> Well, WiaB uses GWT for its webclient - so code wise its actualy Java >> >> both sides, but then compiled to javascript. >> > >> > Yea. I thought about that but pulled back. I looked at GWT. I don't >> > know if >> > we say "foo" in GWT and that compiles to Javascript if that is really >> > going to >> > be "precisely" defined. GWT seems like it was moving rather fast six >> > months ago >> > so the translation of "foo" today may be a lot different than the >> > translation of >> > "foo" a year from now. >> > >> > GWT represents what I don't like about Java. It isn't really using Java >> > directly but using things defined in Java. Each of those things would >> > need to >> > be defined. I've gotten the impression, perhaps mistakenly, that the >> > average >> > Java code could not get back to pure Java code without a tremendous amount >> > of >> > work. >> > >> > Now, it might be that since a protocol is rather simple, that the range of >> > constructs used would be small. But, ultimately, any predefined construct >> > (like >> > an existing Java class or interface) would have to be defined in terms that >> > could be verified. >> > > -- > http://www.fastmail.fm - IMAP accessible web-mail > >
