On the name, Wave is as good as any, so long as we keep differentiating it from GWave. The name email has managed to survive being associated with Qmail, Sendmail and Exchange :)
With regards to communicating with the wider community, as we build the WIAB site and maintain the waveprotocol.org site we need to be very aware of this. I would recommend that we use tools like twitter and so on (continuing to use the #wave tags and #wiab tags to differentiate between the two projects) to reach out beyond the lists. On ProgressOnes efforts, I've had a quick twitter discussion (as me, not as a project committer) and part of the problem he seems to have is the fact that he wasn't sure if he would be welcome on this list due to the WIAB focus. I've pointed him to the list of committers and said that until waveprotocol is up an running properly, this is as good a place as any to talk about the protocols. Hopefully we'll get this sorted as it seems to be a bit of miscommunication on both sides that has led to the proposed fork. James On Sun, Jan 30, 2011 at 11:04 AM, Thomas Wrobel <[email protected]> wrote: > Usage first is a good philosophy - users dont need to know how stuff works. > But surely wave is a necessity for the branding eventually so people > know what works together? Not much point federating if people don't > know they can do it and what with. > > I mean, I know I can "email" anyone if I have their address. Everyone > knows this regardless of if they know what federation means, or smpt > etc. > > However, with someone on ProcessOne, someone on WaiB and someone on > say, Pygowave if they dont even share a "wave" name or logo or > something in common it wont be clear or intuitive they can co-operate. > It would just be random services online. > > The email analogy might not be correct in many case's, but in this one > it seems strong to me - there needs to be a common name that people > refer too, and I think thats going to have to be wave really. > > ---- > > As for a split, I'm still not sure what people mean exactly. > If ProcessOne ends up not federating then thats absolutely not > desirable - we cant have a split before we even have a federation else > we might never get a threshold number of servers working. > If the split just means more concept/features and what not, sure, that > is wanted. > > But to split on the federation to what seems to be due to mere lack of > communication would be a great shame. > > > -Thomas > > On 30 January 2011 00:28, Paul Thomas <[email protected]> wrote: > > That's what I thought, but maybe it wasn't obvious where to turn to for > the stated reasons. > > > > As for the wave brand. the obscurity or terms like 'wave', 'blip', etc > were king of emblematic of the problem with google wave. Not being relatable > to everyday users. > > > > I think it is too late to change the name now, but I suggested it at the > time. > > > > But anyway it doesn't matter so much. Because WAIB plays a different role > the gwave. It isn't so much a specific end use. I it up to those that > implemented to apply it to their use(es), then eventually there will be > cross pollination with federation. > > > > Some things you can't explain to ordinary people why it is better than > the alternative, not matter how much you try, If you hype something too > much, all that is going to happen is their expectations will not be > fulfilled. > > > > When I have a public service, I'm not going to go out of my way to > explain wave or why it is important. I just going to explain the usage in a > familiar way, and have an interface that reflects that. I'm not going to > refer to wave at all, except maybe in a FAQ. When the technology speaks for > itself they will notice that it is better than the alternative. > > > > --- On Sat, 29/1/11, Michael MacFadden <[email protected]> > wrote: > > > >> From: Michael MacFadden <[email protected]> > >> Subject: Re: ProcessOne appears to be forking > >> To: [email protected] > >> Date: Saturday, 29 January, 2011, 22:26 > >> I don't object to a fork at > >> all. That is the nature of open source software. > >> What is unfortunate, is that it seems that this group did > >> not attempt to approach the WiaB community to address the > >> issues before forking. There is an opportunity to work > >> together to reach common goals. > >> > >> As for the protocol. We should invite any one > >> interested in working on the protocol to collaborate on > >> waveprotocol.org. While many of the WiaB developers > >> are the original wave protocol contributors, we welcome all > >> to participate in the evolution of the protocol. We > >> have been slow in migrating WiaB elements off of > >> waveprotocol.org, which would make it more clear that, that > >> is the location where the protocol could be managed from > >> with contribution from all. > >> > >> ~Michael > >> > >> On Jan 29, 2011, at 2:09 PM, Joel Dietz wrote: > >> > >> >> 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] > >> >>>> > >> >>> > >> >> > >> >> > >> >> > >> >> > >> > >> > > > > > > > > >
