[Standards-JIG] proto-JEP: Smart Presence Distribution

Michal vorner Vaner michal.vaner at kdemail.net
Sun May 28 18:10:22 UTC 2006


On Wed, May 24, 2006 at 07:26:17PM +0100, Richard Dobson wrote:
> >>Something to note is this would not be negotiated using stream 
> >>features, this would be negotiated using disco.
> >
> >I dont see how this could be useful for anything but a direct
> >connection, hence the suggestion to use stream:features, where
> >negotiation takes place before the connection is established.
> >
> >>Also, with your protocol how does the sending server know if the list 
> >>is populated yet and how does it know who is already in the list? It 
> >>seems to me that this can easily get out of sync with neither side 
> >>having any way of knowing if it is or not, this is something that 
> >>needs to be resolved, 
> >The worst case for this is rebuilding this list with EACH tcp connection
> >and it is valid no longer than the lifetime of that (e.g. you send
> >a presence broadcast first and after that you only send smarticasts).
> 
> I see... you want to start this new for every connection, yes it could 
> work that way the way you propose it, it does mean that you are only 
> likely to get savings where there are lots of contacts between two 
> servers that have enough traffic travelling between them to keep the s2s 
> connections active for long periods, if they keep regualarly dropping, 
> because of various things like lack of activity for a certain period, 
> you loose the benefit of this, this is a start but IMO it would be 
> better if we are going to standardise a mechanism for this that it works 
> across different connections.
> 
I was thinking about it a bit, and came to an idea. What if every time
the list is changed, the name changes? What if the name of the list is
some kind of hash of the list? You could be sure that if it exists, it
is OK. And the worst thing that could happen would be it no longer
exists and it needs to be rebuilt.

-- 
One semi-random fortune: 

Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
engineer.
                -- Fred Brooks

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060528/6fa68ea9/attachment.sig>


More information about the Standards mailing list