Another way to look at it is that there will (hopefully)be many organizations interested in the wave protocol. Generally there is a working group set up to manage protocols like wave. The job of the workgroup is to represent the desires of the various organizations to ensure changes are in the best interest of all involved. The protocol workgroup will be made up of interested parties and hopefully vendors of many different implementations. Thus the protocol discussion would be mutli-vendor.
On the other hand the WAIB project is about building the best open source wave server / client. Other vendors would have no say in how WIAB is implemented. That would be up to the committers / WAIB community. The WIAB community would likely have a large voice in the protocol community, but be only one of many. Right now its easy to see that the WIAB community and the protocol community are essentially one in the same, but that's only because the current other vendors are interested in helping out with WIAB. In the future, other vendors might want to join in protocol development without contributing to WIAB. And that's just fine. >From that perspective it is clear that for the wave protocol to really be a standard that other vendors could adopt, they would definitely need to be be separately managed things, because the people making the decisions would be two distinct groups with different objectives. If we agree that eventually separation of the protocol and WIAB is the end goal, then it would seem we have two views: 1) Separation is a long term goal, but that we don't need it yet. There is some perceived overhead in separation and the fact of the matter is that both communities are identical at this point. Lets not loose momentum due to bureaucracy and muddy the waters. Managing one project is probably more agile at this point and will allow us to move faster. At some point in the future when things stabilize, we can split them up. 2) There are already multiple vendors and interested parties in play here. Several people involved in wave are working on their own implementations. They have a vested interest in the protocol, but may or may not be able or willing to work on the WIAB codebase. These individuals might become disillusioned with the protocol if it is seemed to be tied to and controlled by WIAB. This could ultimately hurt wave's adoption. It is much easier and safer to set up this framework now that in would be to extract the protocol from WIAB later on. It's clear we have mixed opinions on this. Thanks On Nov 15, 2:25 pm, James Purser <[email protected]> wrote: > Okay, > > The Federation Protocol is separate from the transports it travels over. > Currently we have an existing XMPP transport and a HTTP based transport > being worked on. > > The situation we want to arrive at I think is this: > > Work on the theoretical is done via the waveprotocol.org site. This includes > development of the various protocols (remember federation is just one of the > protocols being developed there, we also have client/server, Robots and > Gadgets). > > Work on the practical is done via the Apache WIAB site. This is the > reference implementation of the work being done on waveprotocol.org. Here we > take the protocols and build an example for others to poke around and learn > from. > > Think of it as a w3c/apache model, one provides the standard, the other > provides the tools. It's just that both groups in this model answer to the > one ctte. > > The other benefit to the above model is that it doesn't scare away those who > want to contribute in ways other than code. > > James > > On Tue, Nov 16, 2010 at 7:27 AM, Michael MacFadden < > > > > > > > > [email protected]> wrote: > > I believe there is a distinction between the Federation Protocol and > > the XMPP Extension. Obviously the Federation Protocol was born as an > > extension of XMPP. It may or may not live on as such forever. > > Currently the XMPP extension is looked at as one possible transport > > for the federation protocol. Other transports such as HTTP are also > > being investigated. > > > I don't think it's clear how that concept will develop, but until > > there is more development it might be premature to manage the > > federation protocol directly under the XMPP project. > > > On Nov 15, 12:10 pm, Dave butlerdi <[email protected]> wrote: > > > Why not run the protocol portion through the XMPP Extension processes and > > > the WIAB as an Apache project with > > > OT and other bits as sub projects. This would solve all of the immediate > > > problems and allow those who have expended > > > energy and budget to get on with their projects. > > > > On 15 November 2010 20:34, antwatkins <[email protected]> wrote: > > > > > My main concern, regardless of where we maintain the protocol vs the > > > > code for the RI, is that it is not a requirement to develop on the RI > > > > that is WIAB to have elevated status on the protocol itself. So if > > > > they are hosted together I think there should be a path for committers > > > > and members of the PPMC that does not require heavy involvement in > > > > WIAB development. Therefore, companies or individuals developing > > > > their own Wave servers or products that integrate through federation > > > > can have equal influence in regards to the protocol. These > > > > individuals would still serve committer roles through maintaining the > > > > website, helping users, monitoring issues, and helping to decide on > > > > release plans. Their focus would just not be code based. As long as > > > > we can accomplish this through the Apache framework, I vote we keep > > > > them together to minimize overhead. > > > > > R, > > > > > Anthony > > > > > On Nov 15, 11:31 am, Tad Glines <[email protected]> wrote: > > > > > I agree that at some point we need to create a standard that is > > separate > > > > from the reference implementation. Once we have a working reference > > > > implementation, we should write and submit a draft to the IETF. Based > > on > > > > what I've read on the IETF site, you have to have a working > > implementation > > > > before a draft will even be considered as a proposed standard. I don't > > think > > > > it matters where we maintain our initial draft documentation. If we > > think > > > > that having a separate waveprotocol.org website will encourage greater > > > > participation and adoption, then that's the way to go. > > > > > > -Tad > > > > > > On Nov 14, 2010, at 9:15 PM, Michael MacFadden < > > > > [email protected]> wrote: > > > > > > > All, > > > > > > > During the Wave Summit we discussed several topics. The possible > > move > > > > > > of the WAIB project to apache incubator has been covered elsewhere: > > >http://groups.google.com/group/wave-protocol/browse_thread/thread/536. > > > > .. > > > > > > > However, in relation to the move to apache, the question of the > > Wave > > > > > > Protocol vs the implementation that is Wave In A Box was raised. > > > > > > Typically apache projects are code oriented. Apache does not > > > > > > typically act as a standards bodies. This is bit of a gray area > > > > > > since new projects applications / utilities often include XML / > > SQL > > > > > > schemas, APIs, and messaging formats that other entities would need > > to > > > > > > adopt to work with those components. These could be considered > > pseudo > > > > > > standards; however, they typically dicate how to use or integrate > > with > > > > > > the tool in question. They aren't really defining a public > > standard > > > > > > that everyone should adopt. > > > > > > > When we were initially discussing the the move to Apache, we > > assumed > > > > > > that both the protocol and the implementation would both transition > > to > > > > > > apache. All content would then be migrate from waveprotocol.orgto > > > > > > the new apache project. However it was brought up that another > > option > > > > > > would be to leave all items relating to protocol development on > > > > > > waveprotocol.org; only the Wave in a Box project (code, docs, > > wiki, > > > > > > etc) would move to apache. > > > > > > > The gist being that WIAB becomes the reference implementation for > > the > > > > > > protocol, but that the two may indeed be managed differently. > > > > > > waveprotocol.org could become the public body responsible for > > working > > > > > > on the protocol. Open discussion and changes to the protocol would > > > > > > happen there. There would be a process for planning and approving > > > > > > revisions to the protocol. Once a revision is published, the WIAB > > > > > > project would then update its codebase to maintain compliance. > > > > > > > A few benefits to this approach are: > > > > > > > - It fosters discipline on managing the protocol. Developers can't > > > > > > simply make de facto changes to the protocol just by modifying the > > > > > > WIAB code. > > > > > > - It is possible that those that theorize about the protocol and > > those > > > > > > that develop the WIAB codebase might not be the same group of > > people > > > > > > (right now their is obviously a large if not total overlap). > > > > > > - It sets us up to move the protocol to a formal standards body > > later > > > > > > on if we see fit. > > > > > > - It gives the impression that we are drinking our own cool aid, > > > > > > rather than running around with scissors. > > > > > > > I would like to open discussion on if this is what we want to do, > > or > > > > > > if we want to manage this all in one spot. There are pros and cons > > to > > > > > > each approach. > > > > > > > Sincere Regards, > > > > > > > Michael > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > Groups "Wave Protocol" group. > > > > > > To post to this group, send email to > > [email protected]. > > > > > > To unsubscribe from this group, send email to > > > > [email protected]<wave-protocol%2bunsubscr...@goog > > > > legroups.com> > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > . > > > > > > For more options, visit this group athttp:// > > > > groups.google.com/group/wave-protocol?hl=en. > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Wave Protocol" group. > > > > To post to this group, send email to [email protected]. > > > > To unsubscribe from this group, send email to > > > > [email protected]<wave-protocol%2bunsubscr...@goog > > > > legroups.com> > > <wave-protocol%2bunsubscr...@goog legroups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/wave-protocol?hl=en. > > > > -- > > > Regards > > > > Dave Butler > > > butlerdi-at-pharm2phork-dot-org > > > > Also on Skype as pharm2phork > > > > Get Skype herehttp://www.skype.com/download.html > > > > ********************************************************************** > > > This email and any files transmitted with it are confidential and > > > intended solely for the use of the individual or entity to whom they > > > are addressed. If you have received this email in error please notify > > > the system manager. > > > > This footnote also confirms that this email message has been swept by > > > MIMEsweeper for the presence of computer viruses. > > > >www.mimesweeper.com > > > ********************************************************************** > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%2bunsubscr...@goog > > legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/wave-protocol?hl=en. -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
