Do the WAIS folks know about this? I wonder what they'd say...
> My question "then what would you recommend instead" provoked no
>useful answer (what is needed is *reliable* datagrams, but these are
>not implemented as an IP protocol; UDP requires too much coding for
>time-out, retransmission and fragmentation). Yet, he convinced me
>that a light-weight protocol like this should minimize the number of
>round-trips.
I agree.
>I have the feeling that the current trend of basing the new protocol
>on NNTP violates that requirement. I like the idea of borrowing
>response and data formats from the FTP/SMTP/NNTP family of protocols,
>with suitable extensions for 8-bit data paths. However I don't like
>it if compatibility with NNTP forces us to have an extra round trip
>just so that the server can give its welcome message.
The idea was to use the existing usenet distributed database. But
I guess we should just use plain old NNTP for that.
>Also, I don't like the fact that you must parse the RFC822/MIME header
>to find out how many bytes are to be expected. This seems to be
>mixing two levels of protocols: MIME assumes that the end of the
>message is already known, and the MIME headers then tell you what to
>do with it.
I certainly didn't think it out very carefully, did I?
>As I see it, there are two possible ways of using MIME in HTTP+. We
>can either support MIME as the *only* data format (implementing any
>extensions we need as new MIME content types or subtypes or additional
>headers), or we we support MIME as one of the possible data formats.
A terminology note here: there is no one "MIME data format." There's
the ubiquitous message/rfc822 format that you can stick anything
inside using MIME techniques. But the basic unit of information
in the MIME spec is an _entity_ -- just an arbitrary stream of bytes.
The question is, when you're sending an entity from one
place to another, how do you know where the end is?