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.
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.
--Grant
On May 16, 2006, at 2:17 , Phillip J. Eby wrote:
At 01:54 PM 5/16/2006 -0700, Alec Flett wrote:
Phillip J. Eby wrote:
I don't think zope.interface will actually buy us anything for
stamping, unless I misunderstand what stamping is used for.
Here's what I suggested to Katie that our stamp implementation
might look like... first, there's an abstract base class for all
stamps:
Fair enough - mostly I personally wanted to make sure that either
someone took a hard look at zope.interface or someone who knew
enough about zope.interface took a hard look at our stamping model.
I think the next two things to worry about w.r.t. stamping are n-
directional relationships and collection membership.
Our current model of stamping makes it really easy to deal with
the the combined event-ness, the task-ness and the mail-ness of
the same item item.. i.e. if I have the event-ness of an item
(i.e. I'm using the startTime attribute) then it is really easy to
get to the mail-ness just by accessing the toAddress attribute.
If we move to an attribute-based relationship, then getting from
event -> task -> mail, or mail -> event -> task or whatever gets
more complex.. What you describe in the code you presented has
this notion that there is one primary object that has a bunch of
stamps associated with it. But what if you've got one of those
stamps (i.e. the sort of 'sub-object') and you need to get to one
of the other stamps?
http://chandler.osafoundation.org/docs/0.6/parcel-schema-
guide.html#annotation-classes
See the last part of this section, where an example is given of
switching between various annotations, e.g.:
>>> Teacher(fMary)
Teacher(Mary Quite Contrary)
>>> Friend(ProfMary)
Friend(Mary Quite Contrary)
>>> Friend(Teacher(Friend(Friend(ProfMary))))
Friend(Mary Quite Contrary)
As you can see, an annotation can be called with either an item or
another annotation, and you still end up with a simple annotation
around the item.
Further, if I stamp some Event as a mail message, and later REMOVE
the event-ness of it.. what happens to the stamps and the
relationships? How does the mail item stick around?
Annotation attributes are stored on the underlying item, so nothing
happens to them when you remove the stamp, unless the stamp's remove
() method chooses to do something special.
This comes up in thinking about collection membership i.e. if
you've stamped a mail message as an event and a task, then how
does the event show up in the calendar? is there a 'primary'
object (that might be a mail message) that shows up, and the
calendar has to look through the stamps looking for event stamps?
Or can we simulate the idea that the 'event' stamp is in the
current collection.
Yes.
Say we want to check if an item is in a given collection. When we
do a kind query for Events, we'll get a stamp, but how to we check
if one of the associated stamps is in that given collection?
It won't be a kind query for events, it'll be a refcollection of
items that have an active Event stamp.
Anyway, my point is that we should figure out how that is going to
look from an API perspective, because it seems frustrating that
we'll have to think about this kind of thing all over the codebase.
I think there's less of a change than you're thinking. It's all
still items, and the same items as are in use now. The only thing
that's different is that instead of kind collections there will be
distinct collections for stamped items.
I think this is one of the reasons I was thinking about
zope.interface and adapters - at least on some level it abstracts
away the concept of a master event and sub-events - if you can
just say to any e-mail message "adapt yourself into an event" and
it doesn't matter who is a sub-object of what, and we can figure
it out under the hood, then that seems good.
I'm not 100% clear here on what you're trying to do, so I can't say
what's the best way to do it. My current proposal is based on the
0.6 notion of what stamping is, i.e. that one object "is a" email
and "is a" event. I haven't been presenting anything for any new
stamping models, and I wasn't aware that a change to the stamping
model was currently in scope.
(And yes we can certainly just make our own API to abstract that
away, but at least that part looks an awfully lot like
zope.interface!)
Or like annotations. :)
On the flip side I don't know enough about zope.interface to know
if there is some way to deal with multiple stamps of a given kind.
i.e. if I have a mail message and I want to say "give me all the
Events that this item is stamped with" (as opposed to just one) or
"add a new Event stamp" - if we couldn't do that, we'd be missing
out on one of the key reasons we wanted to move away from identity-
based stamping...
With both zope.interface and with annotations, you would need to
adapt to an "event owner" interface (or annotation) to do this.
That event owner role would handle keeping track of the N possible
linked items.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
