> Peter wrote:
>> *Some runtime environments constrain the number
of simultaneous HTTP
>> requests a client may make to each connection
manager; if such clients
>> need to connect using more than one account at the
same time, then
>> support for multi-stream sessions is essential.
>>
>> * While XMPP does not allow two sessions with
the same full JID to
>> be open at the same time, it does use one stream in
each direction for
>> client-to-server connections; support for multiple
streams enables
>> clients that connect via the HTTP Binding to
emulate that behavior and
>> thereby reduce network traffic.
I don't understand this second point (even if I assume that
'server-to-server' was meant instead of
'client-to-server').
The intention of the original text was simply to say that
restricted clients
*need* multi-streams if they want to open more than one XMPP
stream (with
different JIDs). Other entities might not need to support
multi-stream
sessions in these cases (they could open multiple sessions
instead), but it
would be much more efficient for them to employ multi-stream
sessions.
(Since with multi-stream sessions only one HTTP request to
the server is
necessary to service all the streams in the session.)
I agree with the rest of Peter's clarifications.
Vinod wrote:
> Shouldn't multi-stream support go into a separate JEP?
This could be
> used on both ends of a JEP-0124 implementation. Eg. an
HTTP client
> using multiple streams to a JEP-0124 server, and the
JEP-0124 server
> using a single tcp connection with multiple streams to
an xmpp server.
IMO multi-stream sessions fitted very neatly into JEP-0124.
Broadening the explicit target of JEP-0124 to include
server-to-server
connections would seem to be a good idea - especially if
people do start
running their own servers (something Peter often advocates).
The existing
JEP would probably only need an extra sentence in the
introduction and a few
minor language changes (e.g. 'client' -> 'entity'). I
think any security
review should take those changes into account.
- Ian
|