I will shortly provide that connection for you, Thomas, in PyOfWave. Please be aware that it may be quite a bumpy ride for both of us as we implement it since we're standardizing at the same time. -- Adrian Cochrane [email protected]
On Mon, 30 May 2011 02:57 +0200, "Thomas Wrobel" <[email protected]> wrote: > 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 > > > > > -- http://www.fastmail.fm - Email service worth paying for. Try it for free
