[xmlblaster-devel] Clarification on socket protocol exception..

["Brad Clements" <bkc at murkworks.com>]

I am working on a new pure Python implementation of the xmlBlaster socket 
protocol

I have a question about the encoding of exceptions

On


http://xmlblaster.org/xmlBlaster/doc/requirements/protocol.socket.html

This example is given

Example of an XmlBlasterException as a response on a publish() (a content is not shown):

   "        84**E**17711*publish*oxf6hZs**QueueOverflow*The destination queue is full*0*"


I am wondering about that last * the one after the 0.

My reading of:

errorCode{string}, message{string}, byteDump of exception

makes me think that byteDump = "0*"

that is, the trailing null is part  of the byteDump.

Otherwise it serves no purpose, since

a) the userData is entirely one single exception "block"

b) userData length is determined from message length.

So, is that last * in the example a mistake, or will there really be an extra \x00 at 
the end of the byteDump?


Also in flag, it says:

90 (typically 'Z') The userData is compressed with gzip (see jzlib and zlib). 
Currently there is support to compress the whole socket stream - in such case 
this flag makes no sense and is not set

How is it that the entire socket stream is compressed? Where do I find the 
specification for that?

Does this mean I should not compress userData using zlib because it's not 
supported?

I am looking at the config docs on this same page and trying to figure out how
compress/type = "zlib" can possibly work. That is, some messages are 
compressed and some are not. How can I split messages out of a tcp stream 
without some demarcation?

I guess only zlib:stream can really work on tcp, and I would have to know in 
advance if I was "sending" everything zlib compressed, and if I was receiving 
compressed data. I guess compression must be the same in both directions.

how does compress/type = "zlib" work with compress/minSize = 500.. ? How can I 
tell if I'm receiving a compressed message and how many bytes it's going to be 
so I know when to stop blocking on a read?


If 'A' adler32 checksum is not supported, why is it in the spec at all?



-- 
Brad Clements,                bkc at murkworks.com    (315)268-1000
http://www.murkworks.com                          
AOL-IM or SKYPE: BKClements