[standards-jig] Thoughts on JEP-0025
m at tthias.net
Fri Jun 7 20:57:07 UTC 2002
>Any example for such an XML document?- I would recommend not to complicate
>it too much.
I don't think it's to complicate to use XML for that. On the server side
this document can just be a static thing - on the client side we already
have XML parsers.
An example how this could look like:
<!-- show that we support the old JEP-0025 protocol -->
<!-- show that we support the new extendable polling protocol -->
<!-- we support SHA magics to protect the pollings -->
<!-- we support destination addressing -->
<!-- the destionations we offer -->
<!-- maybe other polling protocols we support -->
The polling request format can be based on what you already suggested,
but some things I'd like to change:
- I don't think we have to end the list of tokens with a # token. We
just can use an empty one.
- It should be possible for the server to detect if the client decided
to use traditional JEP-0025 or the extendable polling protocol.
Therefore is propose to start the token list with a comma for the
extendable protocol, that is a char that is never the first char in a
- To be able to have more then 26 (A-Z) tokens I propose the separate
"token name" and "token content" (maybe I should call it header type and
header content) with a space char.
A sample request could look like this (I don't show HTTP headers because
we don't have IDs in it anymore):
,EXT 1.0,C 0,N ae01d95cd6f28b1c9873708892714696810d866d,,<?xml
version="1.0"?><stream:stream to="jabber.org" xmlns=".....
,C 7776:2054,,<?xml version="1.0"?><stream:stream ....
,C 7776:2054,H 767425dde2d5512172662986b34d3ef9d3e911d0,,<some other
jabber stream data/>
request with a new hash:
,C 7776:2054,H 70c87a5da2f863a8a91940d812d48137ee055163,N
374b865bb4e96c0033706d29134eade5279f1908,,<some other jabber stream data/>
if the server detects an error, I would propose not to indicate this
with a new session ID but in a way like this:
,C 7776:2054,ERR -1:0,,<content of this reply could be a textual error
>I would however not suggest to use any session IDs if not necessary (for
>example with the hash thing I proposed) for they would waste bandwidth
>then. Keep in mind that here with polling every some seconds every
>additional byte in the request/answer packets will cause a lot traffic
I think compared to what we already transmit (headers of IP, TCP and
HTTP) a session ID is not much traffic. And I don't think it's a waste
of bandwidth: With session IDs the polling server can easily access the
context of a session with a fixed key in a hashed data structure. When
we use the hash as session ID it changes from request to request. We
either have to search a list of all open connections with each request
then or we have to update the key in the hash every time (that means we
have to copy the context with each request).
>I'd say every 5 seconds if busy, every 40 seconds if idle. But after all
>it's a client thing. Whatever you say I would bet client developers will
>use fixed polling intervals ;-).
Peter already wrote that he had implemented this in Exodus and I have
implemented this in the JabberApplet extension too.
>BTW did anyone take a look at for example GNU httptunnel?- Maybe it would
>be a good idea to use some existing mechanism for http tunnelling. Maybe
>not. I'm not sure.
Where can I find information on this project?
Fon: +49-700 77007770 http://matthias-wimmer.de/
Fax: +49-89 312 88654 jabber://firstname.lastname@example.org
More information about the Standards