W3C home > Mailing lists > Public > www-lib@w3.org > July to September 1999

Re: handling multipart

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 19 Jul 1999 17:15:08 -0400
Message-Id: <3.0.5.32.19990719171508.0089ae30@localhost>
To: lex@cc.gatech.edu (Lex Spoon), www-lib@w3.org
At 13:14 19/07/1999 -0400, Lex Spoon wrote:

>From a look at the parser, at appears that all the parts of the body
>are concatenated into the target stream.

That is correct - each multipart entity is passed to a new MIME parser
stream which then passes the data to the same target.

A different mechanism would be to have a callback which called out from the
MM stream whenever a new entity was found. This is easy to do with the
existing stream: Just make the line where the stream stack is set up in the
MM parser a condition of the mode of the stream. You can see an example of
this in the HTMIME.c module where there are several variants of the MIME
parser stream.

The question is what the callback function should call. I would do that the
same way as is done for the HTML parser and the HText interface, that is,
where the stream stack currently is called in HTBound.c, change that so
that instead the callback calls a registered handler with the stream object
and the request object and expects a target in return. This target is then
passed to the stream builder which then will build a MIME parser and hand
the MIME body to the target stream.

>So what I'm really after is this: is there a way to set up a handler
>that can respond to individual message parts as they arrive?  The
>particular application I have in mind would treat the early parts
>as initial versions of a web page, which then get automatically
>updated over time.  But a general answer would be just fine.

I don't remember - does this form for MM come as a special multipart
mediatype, or is it multipart/related?

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Received on Tuesday, 20 July 1999 05:53:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:17 UTC