[Email-SIG] FeedParser: Incremental Payload Reporting

Anthony Baxter anthony at interlink.com.au
Sun Jan 16 17:04:32 CET 2005


On Sunday 16 January 2005 08:55, Clark C. Evans wrote:
> I'd like to use the FeedParser for use parsing multipart/form-data
> from a HTTP POST, and in this case the most common file content is
> binary and the encoding is... none.  Could this be added to the
> wish-list?  It'd also allow cgi.py to be refactored nicely.

Hm. While this seems like a good idea, I'd be a little bit nervous
that it might not be a perfect match - how identical are the requirements
of HTTP and MIME? Completely, or are there vile little gotchas in
the details? The MIME parser goes to extraordinary lengths to deal
with the fundamentally broken nature of much of the MIME that's
generated - as far as I'm aware, web browsers are a fair bit more 
sane (and a heck of a lot simpler).

The partial storage thing, though, is a good idea. As to why it wasn't
implemented - because we didn't think of it during the sprint. As you've
no doubt noticed, the current email parser took a lot of time to get 
right, and this meant we didn't get to everything we could have.
It is, however, immensely satisfying that it's just so damn robust in
the presence of so much utterly utterly shiteful MIME messages 
(*cough* MS Entourage *cough*)

I've also used it on a number of occasions to demonstrate good coding
practices - in particular, the BufferedSubFile iterator (although I still
prefer the original name, ReloadableLumpOfText <wink>)

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


More information about the Email-SIG mailing list