[Standards-JIG] changes to JEP-0138 (Stream Compression)?
brian.raymond at je.jfcom.mil
Mon Mar 28 19:55:55 UTC 2005
I took a look at the features list again for Ejabberd based on a couple of
questions about JEP-0138. It looks like I need to read better next time
because it has a "-" not a "+" beside it so it's not currently supported
On 3/28/05 2:06 PM, "Brian Raymond" <brian.raymond at je.jfcom.mil> wrote:
> 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
>>>>>> only choice we need. If anyone has added this to a server please let me
>>>>> You can just add other <method>s can't you? I expect to see
>>>>> implementations for XML specific compression or encoding in the future
>>>>> 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:
>>>> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
>>>> <compression xmlns='http://jabber.org/features/compress'>
>>>> 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
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards