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
