Re: [Standards] XEP-0051 - Renew that spec?

2009-07-13 Thread Jonathan Schleifer
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Peter Saint-Andre  wrote:

> Why not use TLS-reconnect + XEP-0198 in that case?

This would work as well, of course. I just thought that maybe it would
be nice to not need the whole complexity of XEP-0198. But then again,
code duplication is evil ;). (Same for spec duplication!)

- -- 
Jonathan
-BEGIN PGP SIGNATURE-

iQIcBAEBAwAGBQJKW4hJAAoJEMtRg9d5cXHkb1oP/0363MsS2QeJC1lmGSKnIdbr
3MYfsw8A30NXigvP2+gHmWO28R6Z96NQ0fwKV3sx6BIe/x3GWS6AysS1l9/sGDG5
pQuCYnuaRu8xM/w12+7Ce8aKR7ka0i4k0U6h7DCNXuv3+sGX1oSE6qssZsNypBjg
fEF4a9+uY0uvGt3KDn4Skhu0SpEclMw28EyKwcAKtuUYaQhHG6XttxQrSgAVBCIP
Z1CeCkVR3NILUwg6ugxS+LKlBvT3i3WUZSuzZxJFTqFB2+1zshb2bxmUxWWmxmK7
W+SCSfPDQ//HfZ6el8muJL3u0HPj7ZmOBb5TzUHNneszgnpbLbGzwfFFQvSm94nl
7yQ+WVZIjGUZ6m9eHIkOS0Dw3u65/RH2u2rIJmX1bPsF3lJh2REBZPa2OupZ8DiO
mlrNT50rpfybmvsirADdIX7czhV8V+CLuoMAEH8rECqea0TfIEo81pu+fcoDPets
0d38Qhif5+I5yZ/K6irvk4GcBn2GPoSkfdNdcLxuDb/Wm5ptqDzM+O+d5LlGwbTD
nmhXN8POXO4uLfU5a1Co/ByEmBApIwKWV17sXQv4vAP2oJ/E9gfK4QKnNfug/rmM
OF+5drShzl4AdzVFcKpjgItM028hDQ9lrqVcxS63MPJrjrAlZfOMVbr8Cozm3YLH
+FAJT1hT/BkjM+WGcGHA
=Jpr+
-END PGP SIGNATURE-


Re: [Standards] XEP-0051 - Renew that spec?

2009-07-13 Thread Peter Saint-Andre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/13/09 5:12 AM, Jonathan Schleifer wrote:
> Reading the current XEP, it sounds like the client should do a normal
> reconnect?
> 
> This sounds a bit … disrupting to me. Wouldn't it make more sense to
> also give the client a token and if the client reconnects with that
> token, the old session is resumed? Something similar to XEP-0198, but
> with less overload. The idea is that you get a secret token in the
> XEP-0051 stanza and specify it on connection the server you were
> redirected to so the new server knows where you come from and thus you
> don't have to resend roster etc.

Why not use TLS-reconnect + XEP-0198 in that case?

Peter

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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpbhwwACgkQNL8k5A2w/vwugACg1cvFKXNB+YB90RuY9gzi7MYF
+wAAmwR0rXl0TYz3hu356QSINszGQsgD
=8t8i
-END PGP SIGNATURE-


Re: [Standards] XEP-0051 - Renew that spec?

2009-07-13 Thread Jonathan Schleifer
Reading the current XEP, it sounds like the client should do a normal  
reconnect?


This sounds a bit … disrupting to me. Wouldn't it make more sense to  
also give the client a token and if the client reconnects with that  
token, the old session is resumed? Something similar to XEP-0198, but  
with less overload. The idea is that you get a secret token in the  
XEP-0051 stanza and specify it on connection the server you were  
redirected to so the new server knows where you come from and thus you  
don't have to resend roster etc.


--
Jonathan



PGP.sig
Description: Signierter Teil der Nachricht


Re: [Standards] XEP-0051 - Renew that spec?

2009-07-07 Thread Peter Saint-Andre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/7/09 12:41 PM, Florian Jensen wrote:

> I was just looking for options on how to "loadbalance" / transfer
> connections within a cluster and stumbled upon XEP-0051. I think this
> would be very useful, however, only the second part of it.

I agree that the two parts of that spec are very different. Perhaps you
could take XEP-0051, remove the first part, update the namespaces and
examples, write some better explanatory and introductory text, and
submit it as a new XEP proposal? :)

Peter

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


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpTmjAACgkQNL8k5A2w/vzokACeJmAk0qXK6qK2ukkYLP1CQc/g
UiEAoPFVTGwG7AG/x6UdS6k0/fYvAaWc
=6YZM
-END PGP SIGNATURE-


[Standards] XEP-0051 - Renew that spec?

2009-07-07 Thread Florian Jensen

Hi,

I was just looking for options on how to "loadbalance" / transfer  
connections within a cluster and stumbled upon XEP-0051. I think this  
would be very useful, however, only the second part of it.


In an age of more and more clusters, this could be an essential part  
of cluster management.


Greets,

Florian Jensen