RE: [Zope-dev] zope.mimetype dependency on zope.publisher
Fred Drake wrote: zope.contenttype is a copy/hack of an older version of the mimetypes module from Python's standard library. I'm not sure it's a *good* place to put the functions, but it's probably better than zope.publisher. zope.contenttype has only standard library dependencies, which is an improvement for me. This functionality is thematically related, if nothing else. zope.publisher.contenttype would need to remain for compatibility, but should be able to simply import the functions from zope.contenttype. I experimented (diff attached) by moving contenttype.py to zope.contenttype.mimeparser, then copying tests; with minor search/replace in the copy of tests, this works. If these can be moved, it seems much better to make zope.contenttype a documented dependency of zope.mimetype and change the imports in zope.mimetype to cease importing from zope.publisher. I'll suggest the just copying the implementation module to zope.contenttype.parser. :-) There are tests that will need to be copied as well. Renaming that module to be more descriptive too might be good when it is copied. See attached diff to trunk r79689 (for which tests pass) for what I'm thinking. Thanks, Sean +--+ Sean Upton The San Diego Union-Tribune 619.293.1451Systems Applications Supervisor - Newsroom Information Technology 350 Camino De La Reina San Diego, CA 92108 [EMAIL PROTECTED] +--+ zope.contenttype.diff Description: zope.contenttype.diff ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.mimetype dependency on zope.publisher
All - looking for a bit of input on a dependency for zope.mimetype (zope.publisher) not advertised in setup.py for that package: zope.mimetype.typegetter imports zope.publisher.contenttype for two functions (parse() and parseOrdered()). I'm assuming this dependency is more historical than anything else, but I'm guessing out of ignorance. I'm working on a minimal-dependencies CA application (using zope.schema and zope.component only) that could likely use zope.mimetype in a context outside of a full zope 3 web publishing environment, and I was curious if this particular dependency is purposeful/desired? Thanks, Sean +--+ Sean Upton The San Diego Union-Tribune 619.293.1451Systems Applications Supervisor - Newsroom Information Technology 350 Camino De La Reina San Diego, CA 92108 [EMAIL PROTECTED] +--+ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Collector #2326 - LazyCat bug+fix
FYI, for those inclined to take a look, or anyone willing to apply a patch to ZCatalog.Lazy: http://www.zope.org/Collectors/Zope/2326 This bug affects svn HEAD, Zope 2.10.x, Zope 2.9.x. LazyCat.__repr__() calls __getitem__() in such a way that __add__() functionality is crippled (see collector issue) - causes AttributeError. The problem can be worked around in LazyCat.__init__(), which is what the diff/patch attached to the issue does (does hasattr() check and works around appropriately if lazcat doesn't have '_seq' attribute). Any comments/thoughts appreciated. If this looks good, can someone with commit abilities check this in? Thanks, Sean ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] anon http svn access status?
So: will anon http svn access happen? I'm late to this round of the discussion, but +1. I would suggest https, though, to make it firewall-friendly. Even if this is an anonymous mirror (sounds more likely), it would make sense for community bundle builders (e.g. Plone bundles) to use https URLs for everything, which supposes upstream can provide https. Neither http, svnserve, or svn+ssh are friendly to corporate firewalls - only https (where the firewall can't see the http method verbs because they are inside a TLS session). I've griped about this before: http://www.mostscript.com/weblog/?p=26 Today, I have to put in requests to my company network admins to open up to svn.zope.org:3690 out on a workstation by workstation basis. Their firewall can do a generic TCP socket proxy (network security folks want to run an app-level proxy, so we can only set this up one source IP at a time), and doesn't deal with DeltaV DAV verbs over plain-old http - so https is the only reasonable option for anonymous checkouts. Thanks, Sean +--+ Sean Upton SignOnSanDiego.com Site Technology Supervisor The San Diego Union-Tribune 619.718.5241 [EMAIL PROTECTED] 350 Camino De La Reina San Diego, CA 92108 Plone Powered! plone.org ++ python.org ++ zope.org +--+ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
