What is modification, and why do we care? (was Re: [Zope3-dev] MissingObjectContentModifiedEvent)

[Garrett Smith]

I'm not wedded to this philosophy, but I think Zope should provide as
little application-specific event notifications as possible. I think
even the distinction between 'content' and 'metadata' in the current
implementation is dubious. (I don't believe the 'metadata' events are
even used.) I'd just as soon see a single 'object modified' event that
gets fired by the ZMI interfaces as appropriate.

The rest (I think) is all application specific.

If there are a handful of important indexes (e.g. text), they might
publish an applicable set of events that can be fired by applications
that want to use them. I don't think this needs to be in the core --
each index (or other utility) needs to provide its own event-API.

My take anyway.

 -- Garrett


Jim Fulton wrote:
> MissingObjectContentModifiedEvent)
> 
> 
> 
> A week or so ago, there was a thread on the distinction between
> IObjectModifiedEvent, IObjectAnnotationsModifiedEvent, and
> IObjectContentModifiedEvent.
> 
> I'd like to step back a little bit and brainstorm some use cases
> that, hopefully, illustrate why we care about this.  Here's
> a start:
> 
> - A persistence or versioning system wants to know when objects
>    have changed so that they can save new versions of the object.
> 
>    This needs to be pretty much fool proof.  To do this, I think you
>    really need to do something like what the ZODB persistence
>    mechanism does. Perhaps for versions, once could hook into
>    this mechanism somehow.
> 
> - Record, as meta data, the time that an object changes.
>    My original thought was that this would track only
>    data, not meta-data changes.  This is not what we are doing now.
>    For example, updating an object's DC title changes it's
>    modification time.
> 
>    I'm not sure what we should do here.
> 
> - Update indexes (and other cache-like data structures)
> 
>    There is a thought that perhaps the generated event could
>    contain enough information to eliminate some indexes from
>    use.  This is (mostly) an optimization.
> 
>    In one of his proposals, Uwe suggested including an
>    interface and attributes that were changed as optional
>    information in an event.  In some cases, I think this
>    information could be pretty useful, however, it probably isn't
>    useful in as many cases as you might expect. The common pattern
>    for Zope 3 indexes is that they adapt an object to an interface
>    of interest.  The index can't really know how an adapter
>    computes it's data.  The data are sometimes computed from
>    data in a completely separate interface.
> 
>    Probably the indexes that we *most* want to avoid reindexing are
>    text indexes.  We have a ISearchableText interface that we
>    commonly adapt objects to to get the text to index.  We really
>    can't predict how this text is computed.
> 
>    A safer strategy seems to me to be to have the indexes themselves
>    responsible for detecting changes that they care about.  I'm
>    pretty sure that some of the Zope 2 indexes are careful to avoid
>    reindexing, or at least avoid updating indexes if indexed values
>    haven't changed.  Unfortunately, the Zope 3 indexes don't seem to
>    be doing this fairly straightforward optimization, which is a
>    shame.
> 
> Given the applications above, I don't think that there's value in
> fine-grained modification events that justifies the complecity of
> proposals we've thought of so far.
> 
> Thoughts?
> 
> Are there other applications for modification events that
> I haven't considered?
> 
> Jim