RE: [Zope-dev] Versions: should they die?
If I remember correctly, though, there was still a lot in question about legitimate use cases. The web-services cluster-safety use-case I sketched out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) is still (perhaps) a valid case, but ONLY in a very-carefully constructed application (and even that case leaves me wanting a better app-level way to do it). I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as "official evil" in ZMI. Sean
-----Original Message----- From: Guido van Rossum [mailto:guido@python.org] Sent: Tuesday, June 03, 2003 5:08 PM To: Paul Winkler Cc: zope-dev@zope.org Subject: Re: [Zope-dev] Versions: should they die?
To anyone not following the "Problem committing zope 'version' objects" thread on zope@zope.org: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here.
Comments? Could we get at least some warnings in the ZMI before 2.6.2 final?
IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI!
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________ 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 )
sean.upton@uniontrib.com wrote:
If I remember correctly, though, there was still a lot in question about legitimate use cases. The web-services cluster-safety use-case I sketched out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) is still (perhaps) a valid case, but ONLY in a very-carefully constructed application (and even that case leaves me wanting a better app-level way to do it).
I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as "official evil" in ZMI.
As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only). The problem lies in ZODB.ZApplication.ZApplicationWrapper def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ... As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here? cheers, oliver
Oliver Bleutgen wrote As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only).
The problem lies in ZODB.ZApplication.ZApplicationWrapper
def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ...
As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here?
I think that will only work if there's a Version with the specified name. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
Oliver Bleutgen wrote
As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only).
The problem lies in ZODB.ZApplication.ZApplicationWrapper
def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ...
As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here?
I think that will only work if there's a Version with the specified name.
Have you tried it? I have (with cookies), and it works always. Oh, and for added fun set a persistent cookie. cheers, oliver
I think that will only work if there's a Version with the specified name.
Nope. One of the joys of Versions is that there is almost zero error checking - you can put content into a non-existant / deleted / moved version. And then you can't get it out. It really sucks when you are using more than one zope in the same domain that has versions, and lo and behold you start get objects locked in the other zope's version ;) The joy. -- Andy McKay
Oliver Bleutgen wrote at 2003-6-4 18:24 +0200:
... As you and Guido are talking about the ZMI (which means, AFAIK, the managament interface), let me just say that as far as I understand it, deprecating/marking-as-evil and even removing OFSP/Version.py is not what I would like to see happen (not only).
The problem lies in ZODB.ZApplication.ZApplicationWrapper
def __bobo_traverse__(self, REQUEST=None, name=None): db, aname, version_support = self._stuff if version_support is not None and REQUEST is not None: version=REQUEST.get(version_support,'') else: version='' conn=db.open(version) ...
As I understand it, even if the Version product is removed, just putting at variable named 'Zope-Version' into the REQUEST will cause reads and writes to happen in a version. Am I missing something here?
No, you are right. I see two possible solutions: 1. Make "version_support" dependent on the existence of a product that knows how to enable it. The "Version" product could use monkey patching to enable version support. 2. Use the newly opened connection to check that "version" refers to a version object. 2. is much safer but makes version requests slightly more expensive. However, this should not be a real problem. Dieter
Can I, a humble Zope product developer, please make a plea that anything "marked as an 'official evil'" be made as invisible as possible? (I.e. that you make it disappear unless specifically configured as an option, as was suggested up-thread). Zope is already full of deprecated methods that make learning the "one obvious way to do it" very hard to figure out. The refrain on the ML and in other places is "if the documentation isn't good enough, 'use the Source, Luke'", but have you actually looked at the source? Sorry, I know you have -- but please try to imagine what it looks like to a newcomer who doesn't know their way around like you do. We already have same-named objects defined in multiple places -- are they really all the same object? Are they different implementations of the same object? Are they actually just imports from one module to another? Are they overloaded with additional functionality? Also lots of similar objects -- should I use "Item" or "SimpleItem". Should I inherit stuff from "Globals" or from the files they are actually defined in? It is an important point of information architecture that signs to the user must be graded in order to be most useful -- many signs with the same apparent importance are confusing, and may be worse than no signs at all. Also, whereas you, who are intimately familiar with evolutionary history of Zope's source may be completely aware of what's old and what's new, the newbie developer has little way to determine this. I can look at file dates, and occasionally I can find notes explaining this in the comments. But too often developers say something along the lines of "this is the new improved way to do X". But when did they write that? Last month? A year ago? Longer? I recognize that you all have made steps in this direction for Zope 3 (such as the interface/components concept, which IMHO is a big improvement). Reducing confusion should be a big priority, I hope. And what you don't say is just as good as what you do. Minimalism seems very pythonic to me. ;-) Just my 2 cents. Cheers, Terry On Wednesday 04 June 2003 09:21 am, sean.upton@uniontrib.com wrote:
If I remember correctly, though, there was still a lot in question about legitimate use cases. The web-services cluster-safety use-case I sketched out here (http://mail.zope.org/pipermail/zope3-dev/2002-October/003112.html) is still (perhaps) a valid case, but ONLY in a very-carefully constructed application (and even that case leaves me wanting a better app-level way to do it).
I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as "official evil" in ZMI.
Sean
-----Original Message----- From: Guido van Rossum [mailto:guido@python.org]
To anyone not following the "Problem committing zope 'version' objects" thread on zope@zope.org: It's been proposed that Versions should be at least stamped in the ZMI with big warnings, or possibly disabled altogether. Numerous users have been bit by the fact that versions basically do not work as advertised, leading in various cases to zodb corruption or work that can't be saved. There are other security issues that Oliver Bleutgen raised privately which I won't state here.
Comments? Could we get at least some warnings in the ZMI before 2.6.2 final?
IMO versions do nothing except complexify the code. I believe it's an official Zope Corp position to discourage them for new projects. Yet Jeremy Hylton seems to think that they are somehow useful and has carefully preserved them in ZODB 4 (== Zope 3). If it were up to me, they would have been gone, with a big helping of YAGNI!
--Guido van Rossum (home page: http://www.python.org/~guido/)
-- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Im not keeping up on zope-3 at the moment, whats the plan for versions there? Just wondering if there is any great solution there that can be backported. -- Andy McKay
Andy McKay wrote:
Im not keeping up on zope-3 at the moment, whats the plan for versions there? Just wondering if there is any great solution there that can be backported.
I think the solution for Zope 3 is to move all versioning to the application layer. We've been doing this with CMF (using ZopeVersionControl and CMFStaging) and it has worked out quite well for customer projects. It seems much more reliable than versioning at the database layer. Shane
Andy McKay wrote:
Im not keeping up on zope-3 at the moment, whats the plan for versions there?
Zope 3 will not have versions, as we are talking about them there.
Just wondering if there is any great solution there that can be backported.
Sure. We can disable version support. :) I think that this would be a good idea for 2.7. In the mean time, will address the security issue in 2.6.2. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (703) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
sean.upton@uniontrib.com wrote at 2003-6-4 09:21 -0700:
... I think I agree with the feeling that versions should stay in ZODB, but be depreciated/marked as "official evil" in ZMI.
We should not have components in the core distribution which we mark "official evil". If we really think, they were evil (I do not), we should make them a separate product which can be downloaded and installed by people who want it (like I do). Dieter
participants (9)
-
Andy McKay -
Anthony Baxter -
Chris Withers -
Dieter Maurer -
Jim Fulton -
Oliver Bleutgen -
sean.upton＠uniontrib.com -
Shane Hathaway -
Terry Hancock