May I steer this conversation, in this gap (which is probably your midnight), to any implementation considerations and how to upload my current thoughts to waveprotocol.org.
An example of a implementation consideration is that PyOfWave is built upon the Federation concept of deltas and documents, and reversing that foundation would mean I have to start all over again. I like the idea of using XMPP, but I won't throw a fit if we change it. -- Adrian Cochrane [email protected] On Sun, 29 May 2011 19:03 -0700, "Adrian Cochrane" <[email protected]> wrote: > 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 > -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again
