While I think separation will be valuable in the long term, right now I too would prefer we avoid additional overheads. Having everything in one place has real benefits.
The concern about unilateral (or unintended) changes to the protocol is a good one, but the fact is right now we are changing the protocols. Let's get that done soon, before anyone writes too much more code, depending on current semantics. Once there actually are a number of non-toy implementations (I'm not sure WIAB has graduated from toy yet) then might be the time to recognise the protocol seperately. A. On 15 November 2010 06:46, Ian Roughley <[email protected]> wrote: > At this point, do we need the additional overhead of a protocol website? > I'm thinking here of > projects such as lucene, hibernate and others that created > protocols/standards as part of the > reference implementation. This would avoid unnecessary overhead and > process while we get off the > ground. > > I like the fact that everything is together. The one change that might be > applicable, is to split a > protocol stack project from the server project in the proposal. This way > implementations that are > java-based could re-use the RI easier, and we still have a protocol that > non-java implementations > can reference (although with protobufs we might have a high level of entry > here). > > /Ian > > On 11/15/2010 12:15 AM, Michael MacFadden 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/5363c635e8e950fc > > > > 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.org to > > 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]> > . > 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.
