About XMPP, as long as Wave built on XMPP, are someone here want to participate in making federation with http://buddycloud.com/ , for example?
by federation i mean - we have our real-time typing and other goods, they receive our messages when they are in major revisions, or kind of, or, maybe kind of combined client would be better? i understand - in case of real federation they should really want it to happen too, but, since we are all for one goal (secured, private, community-driven oss for ever-day social communications), i think it's completely possible.. and you? http://buddycloud.com/cms/node it looks like they are serious on intention of pushing another standard to XMPP.org also - there are https://project.jappix.com/ and http://onesocialweb.org/developers.html https://groups.google.com/group/onesocialweb/browse_thread/thread/5e9c4c0cf6a9ee4f (here is a thread on discussion kind of federation between them and Wave, actually) also: - nerds(by best meaning) from - http://about.psyc.eu/ that was there 'all the time' http://kune.ourproject.org/ folks using WiAB successfully http://ostatus.org/ with "an open standard for distributed status updates." talking about XMPP federation on D-Cent.org, soon according to d-cent.org/wiki i believe - a few others actual XMPP Social Networks Projects i can't remember now - like DiasporaX - https://github.com/bnolan/diaspora-x - - I'm sure - it can be a wonderful achievement for FLOSS community(whatever it means) if we could create or use some Open Networking Group where the federation between all these and other - at least - XMPP based - would be discussed.. I think - now is a best time for it - as most of major parties are mature enough to work productively But still in open - in-dev standards and protocols status - so can participate and implement what's needed for that federation to happen. On Mon, May 30, 2011 at 9:19 AM, Yuri Z <[email protected]> wrote: > AFAIK the GWT choice was made cause it allows to code once the OT module - > the same code works on the server and the client and no need to synchronize > the changes. Another advantage of GWT is the ability to render the waves on > the server side re-using the rendering code of the client side. Again - > write once but use twice on both server and client. > > 2011/5/30 Paul Thomas <[email protected]> > >> 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. >> >
