But none of these are end services, they are different ways of implementing services. I suppose it depend what you want to do. What you can do is build a community of users, and also encourage other related community to federate. Then the users of these communities will be collaborating together, whether they understand the significance of the technology or not. I think this is more case if there there is a definite incentive for people to dialogue and collaborate without boundaries, rather then those for being closed and centralised.
The problem is if you are too vague and do not have some sort of starting point or focus, and just big up 'cool' technology you end up like google wave. People wonder what the hell to do with it, and why they went there just because the heard about it. Instead I want to bring it to the users that need it most, rather than expecting them to come to. I think many initial implementation will be set up by and for those that already know each other well and already used to collaborating in a similar way, perhaps in person. Anyway this topic might have gone outside of the bounds of the mailing list not sure. --- On Sun, 30/1/11, Thomas Wrobel <[email protected]> wrote: > From: Thomas Wrobel <[email protected]> > Subject: Re: ProcessOne appears to be forking > To: [email protected] > Date: Sunday, 30 January, 2011, 0:04 > 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] > >> >>>> > >> >>> > >> >> > >> >> > >> >> > >> >> > >> > >> > > > > > > > > >
