Following up to Martijn's observations on the ZTK, I'd like to propose a
clean-up of how we handle content types. There are several unrelated
pieces of code concerned with content types, these include at least
zope.contenttype, zope.mimetype and zope.publisher.contenttype.

- zope.contenttype does some content-type guessing from file names. It's
  just a few lines of code and comes with a table of some 30 associations
  of file-name extensions with content types.

- zope.mimetype is a more substantial package that deals with
  content-type specific marker interfaces.

- zope.publisher.contenttype contains a parser for content-type

I propose merging those two packages and one module into one package,

At present, zope.contenttype doesn't have any dependencies within the ZTK,
and zope.mimetype depends on zope.configuration, zope.component and
zope.interface. zope.publisher.contenttype doesn't import any zope code.

- Switching packages that depend on zope.mimetype would therefore add no
  additional dependencies to them.

- There are three packages within the ZTK and the set of packages under
  review which depend on zope.contenttype: zope.browserresource, and All of them already depend on
  zope.mimetype's dependencies, so there's nothing to be lost for them

- Finally, the same holds for zope.publisher which would only acquire a
  new dependency on zope.contenttype if zope.publisher.contenttype were to
  be merged with the latter.

Further, the parser in zope.publisher.contenttype needs to be made more
conformant with RfC 2045 and be used by other code that does some
content-type matching of its own right now, such as zope.publisher.http.


Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to