Re: RFC: AbiTalk communication protocol suggestion

From: Tomas Frydrych <tomasfrydrych_at_yahoo.co.uk>
Date: Wed May 18 2005 - 14:05:10 CEST

Hi Rob,

Thanks for your comments.

> + The original proposal talked about transmitting the original
> document as zabw, you ponder between base64 encoding or not in your
> getdoc command.

We do not want to limit the format of the base document. It is
conceivable, for example, that the base document could be RTF, or WP
document. There are two options I can see: (1) to convert that to some
document fmt that we support and that can be embeded in xml and feed
that through, converting it at the other end back to the original fmt or
(2) run the original through some neutral filter, such as base64 that
makes embedding possible.

The first option would, I think, require the intermediate document to be
plain abw (unless I am mistaken, zabw, being a binary fmt could not be
embeded directly in xml). It is udoubtedly much faster to do doc ->
base64 -> doc conversion than doc -> abw -> doc (except where the doc is
already abw). On the other hand, base64 will inflate the size of the
document -- whether this is a big deal I do not know, but it only
happens on establishing the connection anyhow.

(There is a third option, to pass the document in xml non-compliant
shape and hack around that when processing the document command, but I
do not want to go down that road, as sooner or later it would come to
haunt us somewhere; Robert Wilhelm's point about using SOAP is a good
one, as that would allow us passing our messages over http, and hence
through firewall, and that would be made easier if we stick to xml
compliance.)

Reflecting on your comments, if the document was to be base64 encoded,
it needs to be made explicit: <document encoding="base64">
...</document>. Then native abw documents (or OpenDocuments) would not
need to be encoded at all.

> + The session has to be established in some way, so it might not be
> needed to send the protocol version each time.

Quite so, perhaps the version attribute should be part of the <token>
pre-request and the <invite> cmd, since that is how the session starts.

> + We will need a way to "download" binary/base64 data to the peer in
> an active session if and image/go-chart/... is inserted at one end.

Yes; the insertion in AW will be represented by a change record
(InsertObject) which would be translated into <insertobject>
</insertobject> command. The actual data would come inside the element,
I think best in the fmt used when we dump it to abw files (base64, IIRC).

Tomas
Received on Wed May 18 14:05:47 2005

This archive was generated by hypermail 2.1.8 : Wed May 18 2005 - 14:05:48 CEST