Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

Re: [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


mborch at gmail

Nov 7, 2011, 1:36 AM

Post #1 of 3 (270 views)
Permalink
Re: [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB

On 7 November 2011 09:17, Ross Patterson <me [at] rpatterson> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )


r.ritz at biologie

Nov 7, 2011, 4:10 AM

Post #2 of 3 (261 views)
Permalink
Re: [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB [In reply to]

On 11/7/11 10:36 AM, Malthe Borch wrote:
> On 7 November 2011 09:17, Ross Patterson<me [at] rpatterson> 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 [at] zope
> 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 [at] zope
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 )


me at rpatterson

Apr 8, 2012, 1:33 PM

Post #3 of 3 (198 views)
Permalink
Re: [Plone-developers] experimental.broken - Graceful handling of broken interfaces and components in the ZODB [In reply to]

Raphael Ritz <r.ritz [at] biologie> writes:

> On 11/7/11 10:36 AM, Malthe Borch wrote:
>> On 7 November 2011 09:17, Ross Patterson<me [at] rpatterson> 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 [at] zope
>> 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 [at] zope
> 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 [at] zope
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 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.