[Standards-JIG] changes to JEP-0138 (Stream Compression)?

Brian Raymond brian.raymond at je.jfcom.mil
Mon Mar 28 19:06:04 UTC 2005


I came into this late but didn't an implementation listed in the thread so I
wanted to pass along the fact that Ejabberd calls out support for JEP-0138.
I'm running it currently because I wanted to run some tests with live
conversations to see the ratio I can get over time.

It turns out from some tests of XMPP dumps outside of the server that zlib
actually makes a pretty good showing against some XML specific algorithms.
I've been looking at it because the CPU cost to the server is much less then
some of the others methods being kicked around for compressed XML.

If anyone else has any input on their experience with different algorithms
please share.

- Brian 


On 3/28/05 1:15 PM, "Joe Hildebrand" <hildjj at gmail.com> wrote:

> I'd be happy to add feature negotiation, if I could think of a use
> case to write examples for.  If we can't find a concrete example, then
> the negotiation can be handled on a per-compression-scheme basis, and
> specified in the spec for that compression scheme.
> 
> 
> On Sun, 27 Mar 2005 17:52:59 +0200, Tijl Houtbeckers
> <thoutbeckers at splendo.com> wrote:
>> On Sun, 27 Mar 2005 17:47:35 +0200, Stephen Pendleton
>> <spendleton at movsoftware.com> wrote:
>> 
>>> 
>>>>> Point taken about zlib. However the overall issue is that the current
>>>>> proposal limits the implementation to zlib. Perhaps the JEP could be
>>>>> rewritten to be more flexible. At this point though I would be willing
>>>>> to test against any server implementation that is out there. Maybe zlib
>>> is
>>>>> the
>>>>> only choice we need. If anyone has added this to a server please let me
>>>>> know.
>>> 
>>>> You can just add other <method>s can't you? I expect to see
>>>> implementations for XML specific compression or encoding in the future
>>>> as
>>>> well. They'd work with this too...
>>> 
>>> I suppose you could add other methods. It does say this in the JEP,
>>> which I
>>> missed, presumably by adding other <method> stanzas:
>>> 
>>> <stream:features>
>>>   <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
>>>   <compression xmlns='http://jabber.org/features/compress'>
>>>     <method>zlib</method>
>>>     <method>foozip</method>
>>>   </compression>
>>> </stream:features>
>>> 
>>> Now my only real issue is that if the future compression methods used
>>> require parameters, or further negotiation, then the current JEP isn't
>>> flexible enough to handle them. However I can't think of any that do - so
>>> that may not be an issue.
>> 
>> You could either put the parameter in "method" name as you orginally
>> suggested. You also do (yet another) stream renegotiation, as described in
>> the JEP for such a new method. Perhaps a generic way of using FNEG could
>> be described in such a JEP as well.
>> _______________________________________________
>> Standards-JIG mailing list
>> Standards-JIG at jabber.org
>> http://mail.jabber.org/mailman/listinfo/standards-jig
>> 
> 



More information about the Standards mailing list