+1 Getting this out to established groups with large commercial followings would be of value if only from the standpoint of exposure. The use of established groups also assists with the perception of this being a discarded technology.
On 16 November 2010 01:39, Michael MacFadden <[email protected]>wrote: > 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%[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%[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%[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]<wave-protocol%[email protected]> > . > 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 here http://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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
