Florent Guillaume wrote:
> On 31 May 2005, at 12:39, Garrett Smith wrote:
>>> That looks good to me. Especially because, using interfaces, we
>>> could theoretically express more than just a set of attributes that
>>> have changed on an object. I'm thinking of:
>>> - having the interface itself add semantics to what a subscriber
>>> could want to do about the change (i.e., it could recognize
>>> IZopeDublinCore and decide to delay its work),
>>> - having the interface express more complex object structure than
>>> just a set of attributes (I'm thinking about XML Schema-derived /
>>> XForms interfaces, where you can represent deep structures).
>>> That's all science-fiction of course.
>> This is my concern :-)
>> I'm seeing a lot of hypothesizing and we should instead be driven by
>> hard requirements/use cases.
> Ah no, I'm saying that in addition to fulfulling existing scenarios I
> have, it also fulfills some fantasy ones :)
>> IIR, the one definite requirement is to provide support for object
>> versioning. But, as Jim's pointed out, this is probably better
>> handled at a lowed level, since there's no guarantee *any* event
>> model will be sufficient.
> That's if you want things to be totally transparent, yes. Which is a
> valid concern, but I'm not sure it's the most expressive choice for a
> system. I wouldn't mind requiring have a small bit of cooperation
> from objects if they want to be versioned properly.
I see your point.
But I think you're asking a lot from the system. It's going to be very
hard to accomplish what you want even with this proposed eventing
scheme. I'd hate to see this increased complexity without any assurance
that it will even meet the one hard requirement driving it.
Have you explored looking at versions at the persistence level? I would
think the Zope 2 community would have a ton of experience that would be
Zope3-dev mailing list