Re: [Zope-dev] Proposal: cleaning up the content-type story
Thomas Lotze wrote: 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, zope.app.file and zope.app.onlinehelp. All of them already depend on zope.mimetype's dependencies, so there's nothing to be lost for them either. A closer look at the actual zope.mimetypes code reveals that it really depends on a great lot of packages which just hadn't been listed among the dependencies. These include zope.app.form so that zope.mimetype ends up with 12 direct dependencies (excluding testing dependencies) and 48 dependencies counting transitive ones, including the ZODB. We should try to resolve some of them, in particular the one on zope.app.form, but we'll likely not get significantly smaller numbers. Therefore I change my original proposal: Let's no longer try to merge all content-type-related functionality into one package but let's rather stick with two packages: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK - zope.mimetype: Zope interfaces for content types plus all the fancy form and icon stuff, preferrably sane dependencies I'm still going to move the zope.publisher.contenttype functionality to zope.contenttype which will ease some packages' dependencies, and I'll try to move some appropriate bits of code from zope.mimetype to zope.contenttype. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Updating the ZTK KGS
On 10/05/2009 02:22 PM, Martijn Faassen wrote: Thomas Lotze wrote: Having worked on and released new versions of a few ZTK packages recently, I'm tempted to update the ZTK KGS (ztk.cfg) accordingly now. However, as there doesn't seem to be an agreed process about this and in an attempt not to step on anyone's toes, I'd like to ask first whether it is OK for any developer to modify the versions listed in ztk.cfg (provided that all relevant tests are passing, of course). I'd currently like to update the following packages: zope.app.apidoc = 3.6.7 zope.app.publication = 3.9.0 zope.error = 3.7.0 zope.location = 3.7.0 zope.site = 3.7.0 zope.traversing = 3.8.0 Thanks for bringing this up. There's indeed currently no agreed-upon process. Jim a while ago was proposing a rather heavy staging process where the trunk can only be changed if a staged branch passed all tests on all platforms (and Python versions) as run by a buildbot. We don't have the infrastructure for this yet and Christian Theune and I were wondering whether this is needed. An alternative process would be to only *release* the ZTK after the compat tests run on all platforms as shown by the buildbot. We do have infrastructure for that. So I'd propose the following development process: * developers can change the version numbers in the ZTK * if the compattests all run, they can check in And then for releases: * we determine we want to make a release of the ZTK * if the buildbot reports it all works on all platforms * we verify there have been no further modifications since then * we can release * what does a release look like exactly? We should at least have a documentation release sitting somewhere on docs.zope.org, with the release number in the URL. The 'current' URL should also point to this documentation. Along with this we should also publish the lists of versions for reuse. How? I would agree with that as a basis for getting started. I think during the course of making the first pre-releases for the ZTK we'll be able to spot issues with that and improve further. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Thomas Lotze wrote: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK Can I suggest that we use a different name? 'content type' to me sounds like CMS-y functionality. We have interfaces like IContentType and methods like queryContentType, neither of which would be relevant to zope.contenttype. :) Maybe zope.mimeparsing or something like that? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Martin Aspeli wrote: Thomas Lotze wrote: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK Can I suggest that we use a different name? 'content type' to me sounds like CMS-y functionality. We have interfaces like IContentType and methods like queryContentType, neither of which would be relevant to zope.contenttype. :) Maybe zope.mimeparsing or something like that? Fine with me. OTOH, there's also good reason to talk about content types since at least the relevant RfCs talk about the kind of strings being parsed mostly (only?) in the context of the Content-Type header field. Personally, I don't care enough to risk bike-shedding about this, though. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
On Tue, Oct 6, 2009 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: Thomas Lotze wrote: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK Can I suggest that we use a different name? Please don't! We have renamed this package already way too often. This ain't funny anymore: try: from zope.contenttype import guess_content_type except ImportError: # BBB: Zope 2.10 try: from zope.app.content_types import guess_content_type except ImportError: # BBB: Zope 2.9 from OFS.content_types import guess_content_type Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: cleaning up the content-type story
Hanno Schlichting wrote: On Tue, Oct 6, 2009 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: Thomas Lotze wrote: - zope.contenttype: parsing of MIME-type identifiers, guessing the MIME type of file contents, preferrably without dependencies within the ZTK Can I suggest that we use a different name? Please don't! We have renamed this package already way too often. This ain't funny anymore: try: from zope.contenttype import guess_content_type except ImportError: # BBB: Zope 2.10 try: from zope.app.content_types import guess_content_type except ImportError: # BBB: Zope 2.9 from OFS.content_types import guess_content_type Actually, that is kind of funny. :) But yeah, renaming is bad. I thought we were making a new package. Ignore my suggestion. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Mon Oct 5 12:00:00 2009 UTC to Tue Oct 6 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Oct 5 20:44:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012712.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Oct 5 20:46:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012713.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Mon Oct 5 20:48:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012714.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Mon Oct 5 20:50:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012715.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Mon Oct 5 20:52:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012716.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Mon Oct 5 20:54:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012717.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Mon Oct 5 20:56:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012718.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Mon Oct 5 20:58:55 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-October/012719.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.site.hooks
zope.site.hooks is a rather light-weight module that is concerned with the concept of a current site, where the notion of a site is used in the same sense as in zope.component, which actually prefers to only talk about a component registry. In contrast, the rest of zope.site deals with local site managers and container stuff including the implementation of folders. IMO it would be interesting to have the concept of the current site available separately from the rest of zope.site with its 30 dependencies. (For example, zope.browserresource demonstrates how with the present zope.site the need to know the current site in order to determine a URL leads to a dependency on the ZODB.) I would propose moving zope.site.hooks to zope.component.hooks if it wasn't for its use of zope.security in order to remove security proxies in two places. These places have rather old comments that suggest reconsidering the handling of security proxies at some point. Right now, the code that removes the proxies is needed but I'd like to raise the question whether we should try to get rid of it. If there's no objection to this goal, I'd like to investigate what it would take. (Even if zope.site.hooks were to remain a part of zope.site, this would rid zope.site of the dependency on zope.security and at least one other package.) -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Updating the ZTK KGS
Hey, Hanno Schlichting wrote: [snip] I don't see how a ZTK meta-egg would be of any value. Given that the number of packages included in the ZTK will change quite a bit over time, it doesn't make sense to depend on a ZTK egg for a package, as it doesn't provide any real stable contract. An egg with hard coded exact version numbers is pretty painful as well, as you cannot override those requirements to go for selected newer versions of any packages pinned in such a way. Opting for a newer zope.testing release for example is quite a common requirement. I don't think it makes sense for anyone to install the entire ZTK. Projects being built on top of the ZTK are most often only interested in a part of the ZTK and will depend on such packages explicitly. What is valuable for those, is the stability contract between various versions of packages in the ZTK. I agree with this - I see little value in a ZTK egg, and I also agree the ZTK explicitly supports using part of the ZTK only. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Updating the ZTK KGS
Thomas Lotze wrote: [snip] - make ztk.cfg available from zope.org (why docs.zope.org, btw?) under a versioned URL I agree we should make it available under a versioned URL somehow. Whether ztk.cfg can be reused directly or whether we should extract something in it with just the version indicators I'm not sure about. I've noticed when modifying the buildout.cfg of the ZTK to add z3c.recipe.depgraph support that I had to pin down *everything* that was pulled in by depgraph as well if I wanted to avoid getting buildout errors (some weird version conflict was taking place). I hope that ztk.cfg isn't triggering that. The reason I mentioned docs.zope.org as the release location is because we will also publish release-specific ZTK documentation when we make a release. The release-specific documentation should be maintained and tagged along with the ZTK itself, and we should have easy access to previous versions of the docs on versioned URLs. But it's true docs.zope.org isn't a very pretty URL for this. Perhaps we should have: http://ztk.zope.org/ This will contain the general intro about the ZTK and the version-independent management information we currently host at http://docs.zope.org/zopetoolkit/ There is also a release overview page, and this gives a list of the ZTK releases. There's also a link to the 'current' release: http://ztk.zope.org/release/current/ which in turn redirects to (or *is*?) the most recent version of the ZTK, for instance: http://ztk.zope.org/release/1.0 The release contains release-specific documentation, including a package list like this: http://docs.zope.org/zopetoolkit/releases/packages-trunk.html It also can contain the dependency graphs for that release, and any other release-specific documentations. (overview of changelogs for all packages?) Finally, and most importantly, it publishes the ztk.cfg for the release. As Hanno suggested, we can also host an index there. The structure might look like: http://ztk.zope.org/release/1.0/ztk.cfg and for the index: http;//ztk.zope.org/release/1.0/index/ I think it makes sense to separate the two and not have the ztk.cfg inside the index. You typically use either the index or the ztk.cfg file independently from each other, I think. As a side discussion: I'm not entirely sure what benefit the index is to the Zope 2 project however; doesn't using a custom index like this stop the project from using any other release on PyPI? I know that Zope 3 has a special index that only locks down Zope 3 dependencies and defers to PyPI for the rest, but that doesn't sound ideal either. A pattern I've seen Tres advocate is of using a custom index per project containing exactly those packages the project needs - how much help would a ZTK index be to support that use case? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bazaar 2.0 (was Re: Subversion externals versus mirroring)
On Sep 14, 2009, at 2:02 PM, Gary Poster wrote: Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least send out a link to it and point out some changes made that specifically address concerns raised by Zope Foundation members when I raised Launchpad's/Canonical's offer before. If there are any questions then, I'll be happy to try to get answers. Bzr 2.0 is out. I personally find the speed improvements very impressive. The new repository format is much smaller, and intended to be stable, and the project has a adopted a six-month maintenance release approach. It has a new website. http://bazaar-vcs.org/en/ It has a new front-end for Gnome/KDE/Mac OS X/Win. The screenshots look impressive to me, which is all I can vouch for. http://doc.bazaar-vcs.org/explorer/en/visual-tour-windows.html Cross-platform end of line conversion is implemented, which was one of the concerns raised earlier. http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion I don't remember if anyone brought up the lack of a parallel to svn externals. That functionality (called nested trees for bzr) is not implemented yet. It is important to Launchpad's usage of the tool, though, so it is in the six-month pipeline, as I understand it. I'm happy to try to field any questions if anyone has any. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.site.hooks
Hey, Thomas Lotze wrote: zope.site.hooks is a rather light-weight module that is concerned with the concept of a current site, where the notion of a site is used in the same sense as in zope.component, which actually prefers to only talk about a component registry. In contrast, the rest of zope.site deals with local site managers and container stuff including the implementation of folders. IMO it would be interesting to have the concept of the current site available separately from the rest of zope.site with its 30 dependencies. (For example, zope.browserresource demonstrates how with the present zope.site the need to know the current site in order to determine a URL leads to a dependency on the ZODB.) +100 if this makes site-aware code have less dependencies. One can really get rid of a *lot* of dependencies this way. I would propose moving zope.site.hooks to zope.component.hooks if it wasn't for its use of zope.security in order to remove security proxies in two places. These places have rather old comments that suggest reconsidering the handling of security proxies at some point. Right now, the code that removes the proxies is needed but I'd like to raise the question whether we should try to get rid of it. If there's no objection to this goal, I'd like to investigate what it would take. We could investigate two options: * just removing that code that remove proxies and sees what happens to significant Zope 3 code bases. Risky. * alternatively, putting in an optional dependency on zope.security in zope.component. If zope.security proxy is importable, try removing the proxies, otherwise don't. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.site.hooks
Martijn Faassen wrote: We could investigate two options: * just removing that code that remove proxies and sees what happens to significant Zope 3 code bases. Risky. * alternatively, putting in an optional dependency on zope.security in zope.component. If zope.security proxy is importable, try removing the proxies, otherwise don't. Please don't add new dependencies to zope.component. Even optional ones, IMHO. It makes it harder to re-use for others and more complex to understand. Many people (e.g. those wanting to use GAE) object to the C stuff in zope.security in particular. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.site.hooks
Hi On Wed, Oct 7, 2009 at 8:49 AM, Martin Aspeli optilude+li...@gmail.com wrote: Martijn Faassen wrote: Please don't add new dependencies to zope.component. Even optional ones, IMHO. It makes it harder to re-use for others and more complex to understand. Many people (e.g. those wanting to use GAE) object to the C stuff in zope.security in particular. Big +1 I am using repoze.bfg on app engine (and in the past a minimal zope3 stack) and getting rid of zope.security dependancies (and/or gutting it) in other packages is not easy and would hate see it turn up in zope.component. T Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Zope-Dev maillist - zope-...@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: Martin Aspeli wrote: Can anyone explain why that condition is there? Otherwise, I'll rip it out. ;-) As I recall, this code is convoluted because it's hard to tell whether an HTTP request is a WebDAV request. If there is now a way to clearly distinguish WebDAV requests, then I imagine this code can be greatly simplified. This code had to deal with Windows 95 and such. There is no way to tell the difference between a WebDAV GET and a normal browser GET, period: the specs explicitly, deliberately overload the GET verb. Hence the IANA-assigned WebDAV source port[1] (9800) (which *we* requested) in order to disambiguate those requests. [1] http://www.iana.org/assignments/port-numbers Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrL/RIACgkQ+gerLs4ltQ51eQCghdRrMOwwIGOGtRIcwzPPRsii pW0AnRe6XOLt9K1epcgJLbaG9C9zZGZX =P+Ba -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2 WebDAV and acquisition
Tres Seaver tseaver at palladion.com writes: There is no way to tell the difference between a WebDAV GET and a normal browser GET, period: the specs explicitly, deliberately overload the GET verb. Hence the IANA-assigned WebDAV source port[1] (9800) (which *we* requested) in order to disambiguate those requests. Heh, nice. Unfortuantely, there's no way to guarantee people will only use this port for Zope's WebDAV server. That said, the two problems (WebDAV requests result in a browserDefault lookup, and folder contents) are not really an issue in everyday use for GET request. They merely cause things to explode on PUT requests to a null resource. We *can* identify PUT requests, obviously. So any comments on my proposal to skip the browserDefault lookup and the acquisition of resources for PUT/PROPFIND/PROPPATCH requests? This is the IPublishTraverse adapter I've had to register for this stuff to work right now. As you can see, I have to undo certain things the default traversal does (nice I didn't want to copy all that code and only modify the one condition needed). http://svn.plone.org/svn/plone/plone.dexterity/trunk/plone/dexterity/browser/traversal.py (ignore the DAV_FOLDER_DATA_ID stuff - that's application specific). Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Updating the ZTK KGS
Martijn Faassen wrote: Whether ztk.cfg can be reused directly or whether we should extract something in it with just the version indicators I'm not sure about. I've noticed when modifying the buildout.cfg of the ZTK to add z3c.recipe.depgraph support that I had to pin down *everything* that was pulled in by depgraph as well if I wanted to avoid getting buildout errors (some weird version conflict was taking place). I hope that ztk.cfg isn't triggering that. I'd say it does; it contains a line allow-picked-versions = false which makes buildout complain if it ends up using a package whose version it had to pick from the index, so you're required to specify a version for every package used by any part of the buildout. This line is a piece of policy that I'd like to see gone from ztk.cfg as well; if someone wants the behaviour, they can specify it in their buildout.cfg. The reason I mentioned docs.zope.org as the release location is because we will also publish release-specific ZTK documentation when we make a release. The release-specific documentation should be maintained and tagged along with the ZTK itself, and we should have easy access to previous versions of the docs on versioned URLs. Agreed. -- Thomas ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
