Re: [Zope-dev] [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB
On 7 November 2011 09:17, Ross Patterson <me@rpatterson.net> wrote:
The intention of this package is to see if the implementation of broken object handling is correct and robust enough to merge into zope.interface and zope.component themselves. Is this the right approach? If not why and what would be better? How might this approach be improved?
(removed plone-dev from cc). Isn't it symptom treatment though? If you've got an add-on which adds marker interfaces to "general objects", shouldn't that add-on remove – or no longer provide – those same interfaces when it's uninstalled? At least in Plone, you can easily query content objects providing a particular set of interfaces. I think it's a non-goal to be able to run a system without all the required software – which is how I understand it when you just do a "hard remove" of an add-on without a prior "soft remove". \malthe
On 11/7/11 10:36 AM, Malthe Borch wrote:
On 7 November 2011 09:17, Ross Patterson<me@rpatterson.net> wrote:
The intention of this package is to see if the implementation of broken object handling is correct and robust enough to merge into zope.interface and zope.component themselves. Is this the right approach? If not why and what would be better? How might this approach be improved?
(removed plone-dev from cc).
Isn't it symptom treatment though?
Yes, it is but the symptom is severe and not uncommon. The problem Ross is addressing here just happens way too often in the real world to simply say "Sorry, user error". Just my 2 cents, Raphael
If you've got an add-on which adds marker interfaces to "general objects", shouldn't that add-on remove – or no longer provide – those same interfaces when it's uninstalled? At least in Plone, you can easily query content objects providing a particular set of interfaces.
I think it's a non-goal to be able to run a system without all the required software – which is how I understand it when you just do a "hard remove" of an add-on without a prior "soft remove".
\malthe _______________________________________________ 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 )
Raphael Ritz <r.ritz@biologie.hu-berlin.de> writes:
On 11/7/11 10:36 AM, Malthe Borch wrote:
On 7 November 2011 09:17, Ross Patterson<me@rpatterson.net> wrote:
The intention of this package is to see if the implementation of broken object handling is correct and robust enough to merge into zope.interface and zope.component themselves. Is this the right approach? If not why and what would be better? How might this approach be improved?
(removed plone-dev from cc).
Isn't it symptom treatment though?
Yes, it is but the symptom is severe and not uncommon. The problem Ross is addressing here just happens way too often in the real world to simply say "Sorry, user error".
Exactly. There is also precedent. The same argument Malthe offers would suggest we shouldn't have ZODB.broken, but we do. We have it because the ZODB is too fundamental a piece of such applications to let it break so completely when code is missing. The same is true of the ZCA, it's too fundamental a piece of such applications to let it break completely when code is missing. Ross
If you've got an add-on which adds marker interfaces to "general objects", shouldn't that add-on remove – or no longer provide – those same interfaces when it's uninstalled? At least in Plone, you can easily query content objects providing a particular set of interfaces.
I think it's a non-goal to be able to run a system without all the required software – which is how I understand it when you just do a "hard remove" of an add-on without a prior "soft remove".
\malthe _______________________________________________ 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 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 )
participants (3)
-
Malthe Borch -
Raphael Ritz -
Ross Patterson