[Standards-JIG] proto-JEP: Smart Presence Distribution
richard at dobson-i.net
Thu Jun 1 10:04:52 UTC 2006
> The problem with this example is that it's likely to compress worse
> than just sending the data anyway. It'll regain the loss over time, I
> think, but it will take a number of presence stanzas. Moreover, you've
> spent an extra round-trip, and it's quite likely this is much more of
> a problem than bandwidth for most circumstances.
The main gain with my solution will be the fact you do not need to
rebuild the whole distribution list every time there is a connectivity
issue or an error.
> My guess is that it'll be tricky to find any approach for this problem
> that doesn't either have serious security implications or is
> effectively compressed away. The amount of additional state required
> to support it is likely to be significant, too, because you're going
> to have one list (whether explicitly or implicitly defined) per
> external user who has any "buddy" on the server, plus one list per
> local user per remote server - all of this needs storage and tracking,
> and seems relatively expensive.
> I'm sorry to pour cold water on a lot of discussion that's gone on
> here, and I do appreciate that a lot of thought has gone into these
> proposals, I just don't think they'll work out.
Yes it does require a lot of state which is pretty much unavoidable, and
I have the feeling too that not many people will actually end up
implementing either method as its simply not that much of an issue for
most people as far as I can see.
>> You will also need to require a jep-ack type protocol as well as the
>> fixes to the cleanly closing of sockets, but yes, although I am not
>> sure what you will think of jep-ack and the related proposals as they
>> all require acking the traffic you send over the TCP socket, which
>> you seem to hate the idea of for some reason.
> I hate it too, which is why I've proposed a solution that reduces it
> to minimal overhead.
Yes which is good too, but you have to agree that we cant just rely on
TCP to ensure the data gets to the other end reliably which Carlo seems
to think will work on its own for some reason.
More information about the Standards