On Wed, May 11, 2011 at 10:08:43AM -0400, James Bursa wrote: > > > > The method of inventing a content type and content handler which then > > rummages around inside a different content handler is full of > > problems. Indeed we have worked to completely remove this method of > > operation and built a data model where it is not supported. > > I agree that this solution is not ideal. > > We probably need to think about this area more. For example, should there be > something between fetching (where I mean the actual protocol stuff) and the > content handling?
That's my preferred option if there's no gopher-specific fetcher (I think I suggested something similar on IRC). One issue we have with the existing curl fetcher is that it is decidedly HTTP-specific. Ideally, we should resolve this (regardless of any long-term intent wrt HTTP support) > Or can we extract the HTML logic from the HTML content code > to make it reusable? This is somewhat tricky, as the HTML handler's interaction with other content handlers is somewhat unclean at present. > Or should we add a way to switch content types? I'd prefer not to support this, as it will generate additional complexity in the caching layer (which is already complex enough imo). I'd much rather we stuck with the current model where any transforms are performed below the low-level cache such that a) we know that a content handler deals with a single content type and b) the necessary transformational ugliness is contained to the maximum extent. J.
