[jdev] Resource binding

[Peter Saint-Andre]

On 2/11/10 9:12 PM, Justin Karneges wrote:
> On Thursday 11 February 2010 19:53:10 Peter Saint-Andre wrote:
>> On 1/30/10 9:22 AM, Tomasz Sterna wrote:
>>> Dnia 2010-01-29, pią o godzinie 07:52 -0700, Peter Saint-Andre pisze:
>>>> You mean http://xmpp.org/extensions/inbox/private-muc.html I suppose.
>>>> It's not clear to me if we absolutely need multi-resource support in
>>>> order to have private MUCs. And I wouldn't want to have a dependency
>>>> on the server to provide private MUCs anyway.
>>>
>>> One may always establish multiple connections to bring up more
>>> resources.
>>> But I think resource binding is way simpler method.
>>>
>>> BTW: What was the exact reasons for dropping it?
>>> I didn't find it nor confusing, nor hard to implement.
>>
>> That's helpful feedback.
>>
>>> Pros:
>>> - does not add another flow, just reuse existing one
>>> - easy to implement (servers already support one resource bind and
>>> multiple connections from one client)
>>> - very straightforward once you get what resource bind is
>>>   (and you need to bind one)
>>>
>>> Cons:
>>> - ??
>>
>> - Changing the existing flows for resource binding
>> - Managing multiple resources on the client side
>> - Knowing when the session is really finished
>>
>> I'm sure were other reasons but I'd need to re-read the list archives to
>> remember them.
> 
> Also, the feature seemed to come out of left field.  Maybe I missed the 
> discussion, but to me it felt like this feature was just a case of "Why Not?" 
> rather than being born from real necessity.  

At the time I knew of some implementations and deployments that wanted
multi-resource support for carrying sessions from multiple processes
running on the desktop, but the people who cared about it didn't ever
get involved in the standards process and I'd prefer not to be a proxy
for such people (if you don't care enough to get involved, why should we
care enough to add your feature?).

> That doesn't make it a bad 
> thing, but I want to remind that we should be conservative about our changes 
> to the core specs.

Agreed. That doesn't mean we can't define an extension for this...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20100212/cbca2ba7/attachment.bin>