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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
