Soren, I completely agree. To add, I think the perception is that we would like it if we can eventually replace the XMPP stack with HTTP. However its to early to tell if that will work and there are also plenty of implementations out there relying on XMPP. Once we have both protocols up and running, the community at large with then decide through the natural selection process which transports will and will not be supported.
If there is large enough support from the community to support both protocols then fine. If not by nature one will die off. ~Michael On Nov 17, 2:47 pm, Soren Lassen <[email protected]> wrote: > I'm supportive of the development of an alternative HTTP transport. > Once it's developed and we gain experience with it, we can look at > what how we prioritise it relative to the XMPP protocol with regard to > deployment and maintenance of specs and code. But it's unnecessary to > dump on XMPP. Despite some difficulties that many of us have had, it's > not fair to say that the XMPP transport is "extremely complex to set > up and maintain". In most cases it has worked really well and has > served us well so far. It's too early to tell how it will stack up to > the upcoming HTTP alternative. > > Soren > > On Thu, Nov 18, 2010 at 8:45 AM, michael.rollins > > > > > > > > <[email protected]> wrote: > > Actually, the group discussion as it took place at the summit was that > > switching away from XMPP to HTTP was the intent, and the sooner done > > the better. The reason for this, which is simplicity, has been > > thoroughly covered by Torben. > > > This distinction is important because it is possible that XMPP > > federation will fall to the side in favor of HTTP and those reliant > > upon it will have to find people in the community willing to support > > it. The entire point of the decision was to simplify WIAB. > > Maintaining two (dumb) transports, one of which is extremely complex > > to set up and maintain, is not simple. It is most likely that any > > implementations will implement one or the other, not both. Due to the > > difficulties involved with implementing them (once again going back to > > simplicity), having two transports could effectively mean that some > > wave servers cannot talk to each other, which would be a detriment to > > wave itself (imagine that you had to check your transport to see if > > you could email someone). > > > So, it needs to be stated that the goal is to replace XMPP with HTTP > > federation. If you are reliant on XMPP for services besides being a > > basic transport, now is the time to speak up, we need to know so that > > we can roll them into the HTTP side if it's feasible. > > > On Nov 17, 12:16 pm, 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 > > 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.
