1. Since - here is a kind of discussion for both c/s and federation i'd better quote 'josephg' from ShareJS, i believe - he could be considered as 'specialist' here:
"..The way I see it, one of the design flaws with wave is that all data is stored in documents. Simply doing OT for key value pairs and lists is very simple. But, google wave requires that all data is stored in documents, so key value pair data is encoded in XML and then stored in a list of XML elements inside a document, which in turn has OT semantics. Its way more complicated than it needs to be, and way harder to implement. A few weeks ago the wave in a box team found yet another bug in their giant complicated OT transform function. If google wave couldn't implement docop transform correctly, I worry about all the 3rd party projects... I don't know what the future of wave is. I wish WIAB wasn't so complicated, and I wish it didn't use so many different technologies (protobufs, json, socketio, xml, xmpp, dns-sd). I think its too complicated for people to muck around with and build things with. I think whatever the future of wave's technology is, it'll be simple enough to be understood in an afternoon and hacked in a weekend. I really like the idea of wave's one-true-messaging platform. But I don't think wave is good enough to be that. Its too complicated and the implementation is too hard to edit. I think we need to distill the best parts of wave and build something that has fewer features and fewer moving parts. I think thats how wave moves forward. But I think you're right - for a project like wave to work, all our disparate projects need to come together and make compatible software." i could, myself, sign under his words as it's obvious that no-one from "other implementations" parties - attracted by Social OT idea's (except WiAB itself, maybe) is federating now, or plan to federate with existing on WaveProtocol.org plan. - good if - only because of WaveProtocol.org became a weak platform in promoting and describing Wave future - now, more realistic - because it's easier and faster to write some Federation and OT from the scratch, than use existing WaveProtocol's one, and it's very , very bad for Wave future, in my opinion. also - http://buddycloud.com/cms/content/meet-us-federated-social-web-summit please - look at their approach, i kindly ask, again, please - someone - while designing new Wave protocols - keep in mind that XMPP rulz - in overall - and if it hypothetically possible to add some compliant ideas for Wave to federate, or in other ways - communicate - with other, at least "friendly" XEP's - that are used in other projects i'v mentioned in post above or else.. It could be Great! Please, take a moment - considering that. 2. > > We should be moving all of the Wave in a Box stuff off of waveprotocol.org > and making it clear that it is the home of the protocol working group. +1 On Wed, Jun 1, 2011 at 1:15 PM, Michael MacFadden <[email protected]> wrote: > > Just to chime in. My hope was that waveprotocol.org would be the pristine > place to discuss the protocols dealing with wave. We should be moving all of > the Wave in a Box stuff off of waveprotocol.org and making it clear that it > is the home of the protocol working group. We just haven't gotten much > tracking on the Apache Wave site yet. Two comments: > > 1) I think we need to have some official sing up for the group that will be > the initial protocol stewards. > > 2) I hope that the client server protocol and the federation protocol both > get managed here. > > ~Michael > > > On May 31, 2011, at 9:33 PM, Adrian Cochrane wrote: > > > O.K., I'll put put it through your system when I'm done. However, I > > agree with Paul to say that the protocols should be handled > > independantly of any of our systems. I was hoping waveprotocols.org > > could be filled with the protocols I discussed without anything > > implementation specific, and that method wouldn't allow me to do all I > > want to do with the site. > > > > Just checking, reading in on your silence on some questions, you like my > > writing style (I have clarified that it's a clarification) and you don't > > have any concerns in implementing the protocols I'd put up at this > > point. I also get the sense people don't want Federation to change. If I > > don't get any response telling me I'm wrong, I'll assume I'm right. > > > > If people don't want Federation to change, I would like to suggest that > > a minimal Federation-Host be developed to power some decentralized waves > > on the site, and we can use Wave to develop further protocols. > > -- > > Adrian Cochrane > > [email protected] > > > > > > On Tue, 31 May 2011 09:35 -0700, "Soren Lassen" <[email protected]> > > wrote: > >> Hi Adrian, > >> > >> Your contributions to the federation protocol are very welcome. The > >> spec at waveprotocol.org is generated from a master file in the > >> wave-protocol code repository: > >> http://code.google.com/p/wave-protocol/source/browse/#hg%2Fspec%2Ffederation > >> (The .html file is generated from the .rst master file.) > >> > >> There are other specs and white papers under the spec and whitepapers > >> top level directories in the repository. > >> > >> You can send changes to the spec for "code" review using the same > >> tools and processes as we use for source code. See: > >> http://www.waveprotocol.org/code/submitting-code > >> > >> Soren > >> > >> On Mon, May 30, 2011 at 4:31 PM, Adrian Cochrane <[email protected]> wrote: > >>> I just typed it up on my computer and I haven't got site access yet and > >>> am waiting to be told how to get in. > >>> > >>> This protocol is the same server-server protocol, but I am to clarify > >>> certain sections. > >>> -- > >>> Adrian Cochrane > >>> [email protected] > >>> > >>> > >>> On Tue, 31 May 2011 00:47 +0200, "Thomas Wrobel" <[email protected]> > >>> wrote: > >>>> Where have you written this? > >>>> Did you manage to get site access? > >>>> > >>>> Also, are you sure "Federation Protocol" is a good name for the c/s > >>>> protocol when the wave server protocol itself is also called "wave > >>>> Federation Protocol". I hate (really) hate wasting time discussing > >>>> names but don't you think people might get confused? > >>>> Maybe something in front or behind to clarify its purpose? Federation > >>>> Hock? Federation Link? Something that indicates its the client to > >>>> server protocol rather then the server to server one. > >>>> > >>>> On 30 May 2011 21:23, Adrian Cochrane <[email protected]> wrote: > >>>>> I have started writing the first standard, Federation Protocol, which > >>>>> (for reasons I already discussed) isn't changing much, but merely > >>>>> clarifying. It involves some C and (not too clearly psuedocode), and > >>>>> shortly DTD. I have also marked the top section up so that with a jQuery > >>>>> widget, it will collapse. I did this so as to follow Apple's HIG and > >>>>> only show what you want to read. > >>>>> > >>>>> Please give me feedback on my writing. > >>>>> -- > >>>>> Adrian Cochrane > >>>>> [email protected] > >>>>> > >>>>> P.S. Sorry about the last eMail, clicked send a bit early. > >>>>> > >>>>> On Mon, 30 May 2011 19:17 +0300, "ya knygar" <[email protected]> wrote: > >>>>>> Adrian, about prototyping and pseudo-code please take a look at > >>>>>> https://github.com/JonathanAquino/noweb.py > >>>>>> > >>>>>> On Mon, May 30, 2011 at 6:41 PM, 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. > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> http://www.fastmail.fm - One of many happy users: > >>>>> http://www.fastmail.fm/docs/quotes.html > >>>>> > >>>>> > >>>> > >>> > >>> -- > >>> http://www.fastmail.fm - Or how I learned to stop worrying and > >>> love email again > >>> > >>> > >> > > > > -- > > http://www.fastmail.fm - The way an email service should be > > >
