[Vortex] Are content-types and transfer-encodings supposed to work?

[Jens Alfke]

On 13 May '08, at 11:54 AM, Robert M. Münch wrote:

> Can you give an example where it makes sense to use this Vortex  
> feature?

I want to compress some message bodies (using gzip). I'm sometimes  
bandwidth-constrained, and markup like XML / JSON / YAML compresses  
extremely well (sometimes 10::1.) The most natural way to do that  
would be for the sender to add a "Content-Transfer-Encoding: gzip"  
header, as HTTP does.

Without that, I have to do something like insert a flag byte in front  
of the payload that's set to 1 if the payload is zipped. Yuck.

In general, BEEP was intended to save people from having to re-invent  
the same wheels over and over. Inventing new data formats and  
conventions for annotating data is a major source of that. It's a lot  
cleaner if you can send the payload in a standard format, whether it's  
XML or JPEG or whatever, and have a mechanism for attaching metadata  
to it, like types and encodings and dates and whatever. That's been  
ubiquitous ever since at least RFC 822.

Unfortunately, such issues are now the least of one's problems with  
interoperability, since Vortex is accidentally using a private mutant  
protocol that isn't compatible with BEEP...

—Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1875 bytes
Desc: not available
Url : http://lists.aspl.es/pipermail/vortex/attachments/20080513/ac438289/attachment.bin