On Feb 11, 2013, at 6:25 AM, Stefan Strigler <ste...@strigler.de> wrote:
> Hi, > > Am 08.02.2013 um 23:55 schrieb Matt Miller <linuxw...@outer-planes.net>: > >> In working on the patch to address HTTP pipelining, I cascaded into section >> 16: Multiple Streams. >> >> Multiple Streams seems to require support for HTTP pipelining, but feels as >> if it runs afoul of even the basic requirements for HTTP pipelining (not >> including the "SHOULD NOT use pipelining with non-safe or non-indempotent >> methods"). I have a hard time working out my patch without doing something >> substantial about Multiple Streams. > > As to my understanding Multiple Streams do not require HTTP Pipelining. > Actually the XEP says that Mulitple Streams might come in handy in case HTTP > Pipelining is not available. > One does not need Multiple Streams (as vaguely defined in BOSH) to overcome the lack of HTTP pipelining. Perhaps there is intermingling of the term connection reuse (using a single socket connection for multiple HTTP request/response pairs, serially) with HTTP pipelining (sending multiple HTTP requests in parallel over the same socket connection). XEP-0124 does make some mention opening a new socket connection to send a stanza if the previous request is still held pending a response. This is what every BOSH implementation I've worked with does today, without the BOSH definition of Multiple Streams. In fact, I'm working on a patch to XEP-0124 that (attempts to) better explain this concept. >> Does anyone actually implement this, and depend on its support? If so, then >> I think we ought to separate this into its own XEP, and fixing all of the >> vagueness and ambiguities around it. If not, then I would STRONG RECOMMEND >> removing it completely. > > Some years ago I ran into an issue where we wanted to deal with multiple XMPP > session at the same time and due to browser restrictions couldn't create more > simultaneous BOSH sessions. That's why we came up with this proposal at first > hand. But then we never had it implemented. While I can understand the use-case, the fact we're hard-pressed to find implementations tells me this is a candidate for removal. - m&m Matthew A. Miller < http://goo.gl/LK55L >
smime.p7s
Description: S/MIME cryptographic signature
