AW: [Members] Stream compression (JEP-138) and notification of failureor success

Alexander Gnauck gnauck at ag-software.de
Wed Jan 11 10:38:15 CST 2006


Hi Gato,

I think we should discuss this on the standards list.

Contact me under the email address in my sig and i will send you test client
with our implementation.
It works like pandion and it works with the Soapbox server, which is the
correct way in my opinion.

Alex
 
Mit freundlichen Grüßen
Best Regards

Alexander Gnauck

AG-Software
Haagstr. 12
74080 Heilbronn
Germany
tel: +49 7131 2798070
fax: +49 69 13304024046
mobile: +49 160 2531388
mailto:gnauck at ag-software.de
xmpp:gnauck at myjabber.net
http://www.ag-software.de



> -----Ursprüngliche Nachricht-----
> Von: members-bounces at jabber.org 
> [mailto:members-bounces at jabber.org] Im Auftrag von Gaston Dombiak
> Gesendet: Mittwoch, 11. Januar 2006 17:13
> An: JSF members discussion list
> Betreff: [Members] Stream compression (JEP-138) and 
> notification of failureor success
> 
> Hey guys,
> 
> When implementing JEP-138: Stream compression my initially 
> understanding was that <compressed> was being sent by the 
> server once he was able to switch to compression mode and all 
> validations have passed (e.g.
> compression is available, compression is not already in use, etc.).
> However, when testing against Pandion I found that Pandion 
> was waiting for the <compressed> notification to be sent 
> before compression is active. 
> 
> The reason for that is that the client was expecting a 
> confirmation from the server saying that there was no 
> <failure> and that compression can be established. And if a 
> <failure> stanza was sent to the client then the client will 
> still be able to parse it since compression is still not 
> active. In other words, <compressed> is being used just like 
> <proceed> in TLS.
> 
> After chatting with Sebastiaan Deckers (author of Pandion) I 
> decided to change Wildfire implementation and follow the way 
> Pandion was using it since the explanation seemed logical to 
> me. Moreover, Soapbox is also following this idea. I wanted 
> to test wildfire with Exodus in order to confirm that exodus 
> is also following this approach but until now I was not able 
> to obtain a binary version of Exodus that supports stream compression.
> 
> Since we now have 2 servers and 1 confirmed client that are 
> using <compressed> as <proceed> in TLS, I was thinking that 
> we might need to make a few small changes to the JEP. We 
> would need to change <compressed> to <compress> and also make 
> it more clear that <compress> should be sent before 
> compression is active and after all validations have passed 
> (i.e. no <failure>)
> 
> What do you think?
> 
> Regards,
> 
>   -- Gato
> 
> 



More information about the Members mailing list