As an interesting aside, it seems like the protocol is now split in to two parts.
1) The format and contents of the Protocol Buffer stack and the actual meaning of those messages. 2) One or more transport layers which coordinates the delivery of #1. It is completely reasonable that we can manage a standard set of Protocol Buffer messages which need to be supported by whatever transports come in to existence. ~Michael On Nov 17, 9:16 am, Michael MacFadden <[email protected]> wrote: > To echo Torben.. > > There is nothing inherently bad about XMPP. XMPP when used as > intended is fine. Originally XMPP was leveraged because it brought > discovery and inter server security to the table out of the box. > There was also the XMPP Brand name which was helpful to get the > protocol going (in my opinion). If the wave protocol had evolved as a > pure XML messaging scheme / extension to XMPP then I think we would be > in a different spot. However, it was deemed that the verbosity of the > XML messaging was just to inefficient. So we packed the wave messages > into ProtoBuf. > > This basically means that the XMPP stanzas are just envelopes carrying > a "black box binary protocol" (forgive the inaccuracy of that term). > At that point, we lost all of the XML Human Readableness that XMPP is > all about, and XMPP was relegated to a simple transfer protocol for an > otherwise "open but proprietary" protocol. Basically, we lost all of > the "advantages" of the XMPP protocol. We were still left with the > advantages of leveraging the XMPP servers though to handle disovery, > etc. > > However, it became clear that you could swap out the XMPP transport > layer with something like HTTP and be much more efficient. As Torben > mentions you would have to re-implement the discovery services. > > In any event to clarify, at the moment, we are not talking about > switching from XMPP to HTTP we are simply defining another transport > layer that the ProtoBuf protocol could flow over. WiaB can support > both and we can see what the adoption is. > > On Nov 17, 7:34 am, Ian Roughley <[email protected]> wrote: > > > > > > > > > One of the issue for us at Novell Vibe, is that it's not trivial, or even > > easy, to integrate our > > user access control with existing XMPP infrastructure products - causing > > some gaps that we weren't > > fond of. Along with this, XMPP was additional infrastructure that requires > > both hardware resources > > and expertise, adding to the complexity and cost of deployment (rather than > > utilizing existing HTTP > > infrastructure). > > > /Ian > > > On 11/17/2010 07:35 AM, Dave butlerdi wrote: > > > > Perhaps, however some of us have substantial development efforts that, at > > > least in our case, > > > leverage XMPP. In the end it really does not matter what decisions are > > > taken and several > > > protocols may be developed/deployed/available however there has been > > > effort using the XMPP proto. > > > > Secondly, I have a difficult time understanding the difficulty in setting > > > up and integrating XMPP > > > servers. If this truly is a problem would it not be wise just to clean > > > this up > > > making it substantially easier for non XMPP folks ? > > > > Regards > > > > Dave Butler > > > > -- > > > 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 > > > 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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
