[Chandler-dev] stamping as annotations?

[Phillip J. Eby]

At 01:35 PM 5/18/2006 -0700, Grant Baillie wrote:
>In the the annotation scheme of doing things, is there a way for
>different kinds to customize behaviour when getting stamped? For
>example, a certificate might want to encapsulate itself as an
>attachment when stamped as mail, whereas events turn themselves into
>invitations.

Sure, you can delegate some behavior back to the underlying item, via the 
annotation's ``itsItem`` attribute.  That is, a method on the Stamp can 
call back to a method on the original item using ``self.itsItem.whatever()``.


>BTW, the other thing in Katie's email that brought the whole
>interface/adapter model to mind, and maybe a more compelling place
>than stamping, was having items adapt themselves when being displayed
>in different contexts in the UI.

I would translate that as the UI asking for annotations that are specific 
to the display context, but certainly adaptation is a possibility there as 
well.

The point of using Annotations isn't to substitute for adaptation, it's to 
annotate items with additional data.  Stamping itself meshes well with that 
concept.  Adaptation is an somewhat-independent concept that might also be 
useful for various things.

Adaptation by itself, however, is *not* a solution to the stamping problem, 
because it doesn't address how additional attributes get stored, indexed, 
displayed, etc.  Annotation solves that problem nicely, and also can do 
many of the things that can be done with annotation.  The rest of the 
things that adaptation does can likely be handled by adding some extra 
features to the Stamp base class, for example to return all the stamps that 
implement some interface.

I feel I should mention, by the way, in case there's any appearance of 
conflicted interest, I actually am a co-author of zope.interface (i.e. I 
wrote the zope.interface.advice module) and much of the current 
implementation of zope.interface is based on design ideas either borrowed 
from PyProtocols or based on an API and terminology design that I 
significantly contributed to.  So, either way you're going to be using my 
code and/or design here.  ;-)  I just mention this so nobody gets the 
impression I'm arguing for the Annotation approach because I wrote it.  The 
real reason I'm arguing for it is that I wrote it specifically for 
Chandler, the repository, and stamping.

Adaptation can do some cool things too, but I'd be wary of introducing 
interfaces and adaptation into the pool of things that developers have to 
understand in order to play in the platform.  I'd want to see whether 
less-general mechanisms that are more specific to our platform could work 
first, so that instead of having to learn interfaces and adaptation to do 
stamping, you just "learn to do stamping".