At 12:56 -0700 10/21/03, Clark C. Evans wrote:
On Tue, Oct 21, 2003 at 09:25:48PM +0200, Elizabeth Mattijsen wrote:
| At 15:18 -0400 10/21/03, Dan Sugalski wrote:
| >On Tue, 21 Oct 2003, Clark C. Evans wrote:
| > > If you are going to go this far (including content-length) may I
| > > just suggest using a MIME envelope? This has several advantages:
| >This is a very good idea, but not this time, as it's too easy to get stuck
| >in the endless churn of very good ideas and alternatives.
I should have just suggested RFC822 like headers (used by E-Mail
and HTTP) and not imply that MIME, with its multi-part and encoding
glory need be supported. In other words, the header could simply be:
Parrot-version: 0.3
Content-type: binary/parrot <- or text/yaml, text/xml
Content-length: 49384
<- blank line (binary payload)

But do we always need that? In my idea it would be something like:


prrt 1.0 yaml # prrt = magic word, 1.0 = parrot header version, yaml = encode ID
Parrot-version: 0.3
Content-type: binary/parrot
Content-length: 49384


(binary payload)


The Parrot header line would just be enough to get the right decoder, whatever the decoder does with the rest of the stream, is up to the decoder. Another example with XML:


prrt 1.0 xml # assume XML
<?xml version="1.0" encoding="iso-8859-1"?>
<parrot
xmlns:parrot="http://www.parrotcode.org/0.3"; # implies MIME-encode binary data
(mime encoded binary data)</parrot>


And another one with an oldy but goody?

prrt 1.0 storable   # assume storable
(whatever Storable.pm puts in its magic)


Hope this made sense.



Liz

Reply via email to