Jan-Wijbrand Kolman wrote:
-1 for using the "guessed" value over the one from the headers; +1 for using the argument over the guessed value (so that the application can "fix" the problem). I agree that having different clients supply different types is painful, but I don't think that "fixing" it at the low level is reasonable (mechanism vs. policy).
Can you elaborate a bit more on the "mechanism vs. policy" remark? I'm not sure I understand your line or reasoning and I'm curious for it :)
OK. The OFS.Image code we are talking about is fairly low-level, and is used widely across applications. It should thus be as "policy-free" as possible, so that applications which need different policies can still reuse the mechanism. Thus, it should *never* override the values passed explicitly by the application (which are themselves "policy").
Overriding the header value passed by the client itself with one guessed by mimelib is *also* a policy, and one which the application could / should make; otherwise, we end up with the alternate problem, which is that clients which do the Right Thing get stomped on.
"Guessing" should always be last in line, and used (at least by default) only in the absence of explicit information.
Tres Seaver [EMAIL PROTECTED]
Zope Corporation "Zope Dealers" http://www.zope.com
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce