Theres lots of ideas here, but maybe better discussed in a more general apache wave thread? Almost all of this is server/server stuff that would effect the wfp as a whole - not directly relevant to trying to make a common c/s standard to connect to wave servers. Not sure you will get many replies here :)
On 30 May 2011 17:41, ya knygar <[email protected]> wrote: > 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. >>> >> >
