james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Stream-based MIME Parser
Date Wed, 03 Mar 2004 22:40:25 GMT


> OK.  So, let me make sure I have this straight.  There are MIME types 
> that are, to the parser, opaque--it doesn't actually need to be aware of 
> these types or how to handle them, it just needs to return the content 
> to the caller (handling the proper decoding if necessary).  For example, 
> application/*, audio/*, video/*, image/*, text/*, etc.

Yes.

> Then there are MIME types that have structural semantics to them, e.g. 
> multipart/*, message/rfc822.  The parser DOES need to understand these 
> types.

Yes again.

> 
> Is that accurate?

I think so, yes.


> And by "new MIME types" you're referring specifically to additions to 
> the latter group, that would require the parser to be modified?

Mainly, yes, but also other things like new encodings  which can be added to the list of legitimate
"things" without requiring a new version of any RFC to be produced.

The point is that there are some things specified by a fixed version of an RFC, but others
are taken from a list of allowed values.

Where the item is on a list, like content types or encodings, you would have a much more future
proof product if you design in the ability to add appropriate functionality in these areas
without the need to modify the code which complys with the more static RFC specifications.

d.

> 
> -jmc
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message