> However any reference to Wave is historical. it should be abundantly obvious > by now that WAIB isn't necessarily going to follow Google Wave's intended > roadmap. Nor should it.
I think maintaining the "Wave" brand is important even though for many non-developers it only has the association of Google's failed problem. > I don't know why some people don't see wave moving on as a good thing. I > mean, it would be worse if they had to backward support GWave despite being a > poof of concept, rather than finding out what is the best path for the > technology. GWave is a lot of things. I don't think there is any backward support necessary for the Wave Protocol, nor, AFAIK, is there any need to fork it. Anyways, re: "moving on" I think we are all benefited by keeping the Wave eco-system as large as possible, so that many of the developers which contributed to other aspects (other server implementations, robots, gadgets, etc.) will also contribute to WIAB as possibilities become available to do so. Good communication with the wider developer community is essential here, something that wasn't a particular strength of Google's. As you say, we need to move forward. > > --- On Sat, 29/1/11, Joel Dietz <[email protected]> wrote: > >> From: Joel Dietz <[email protected]> >> Subject: Re: ProcessOne appears to be forking >> To: "wave-dev" <[email protected]> >> Date: Saturday, 29 January, 2011, 20:42 >> > It's just a silly marketing >> stunt most likely. >> >> I don't think so. According to my understanding Mickaël >> Rémond is a >> long standing contributor to the XMPP community and was one >> of those >> (present at the initial Hackathon) who also made a >> commercial decision >> to implement Google Wave on good faith that Google would >> deliver what >> was promised at the initial Google I/O announcement. >> Especially for >> folks that were developing their own alternative servers >> (ProcessOne / >> Pygowave) on the basis of the protocol, it is >> understandable why there >> would be misconceptions about the on-going project ever >> since it was >> renamed WIAB and moved to Apache. >> >> This confusion is increased by the fact that it is called >> Wave in a >> Box and not simply Wave, since there still needs to be a >> way to >> contribute to the Protocol itself (presumably through the >> Apache >> project, although I don't see that explicitly documented >> anywhere). >> In fact, in the comment thread (highly worth reading, IMO), >> Mickael >> expresses his interest in contributing to the evolution of >> the >> protocol. I suspect there are many others similarly >> confused. >> >> Another point made on the comment thread is that even if >> XMPP and HTTP >> federation are both supported from the standpoint of the >> Apache >> project, this means that any server implementation which >> does not >> support one or the other will not be able to federate with >> everyone >> else -- which seems counter to the whole purpose of >> federation. >> >> Regards, >> >> Joel >> >> >> >> Well, http is just going to be an -option- the >> server hosts can use right? >> >> >> >> To be honest, I'm not too keep on http either but >> I don't see any >> >> problems with it being an option, as long as >> federation can still work >> >> on xmpp as well, it seems there isn't an issue >> here :? >> >> Not sure why there needs to be a split for them. >> >> >> >> ~~~~~~ >> >> Reviews of anything, by anyone; >> >> www.rateoholic.co.uk >> >> Please try out my new site and give feedback :) >> >> >> >> >> >> >> >> On 27 January 2011 23:48, James Purser <[email protected]> >> wrote: >> >> > >> >> http://www.process-one.net/en/blogs/article/xwave_a_tribute_to_google_wave_team/ >> >> > >> >> > So it appears that processOne is setting >> themselves up as an alternative >> >> > reference implementation based on the fact >> that they don't like the work >> >> > being done on the http version of the >> protocol. >> >> > >> >> > James >> >> > >> >> >> > >> > >> > >> > -- >> > --------------------------- >> > Prof. Torben Weis >> > Universitaet Duisburg-Essen >> > [email protected] >> > >> > > > >
