I've got bug 2117 assigned to me ("3rd party parcels can easily foul up stamping")..
http://bugzilla.osafoundation.org/show_bug.cgi?id=2117
I'm planning my 0.6 work, but I don't think we've settled on a solution to this issue (and I'm not even sure that we need to). I've added the comment below to the bug:
The original report said that it's possible for developers to misunderstand howRather than have a design discussion in bugzilla ;-), I'm reopening the discussion here: Phillip, Lisa, Content-model folks -- your thoughts?
to implement extensions to our content model, by subclassing Item (or
ContentItem, or ChandlerItem, whatever) instead of creating a Mixin that holds
just their thing's attributes.
Phillip makes interesting suggestions about a way to significantly rethink the
content model: that is, to do stamping by adding references to the
formerly-mixin class instead of doing actual mix-in merging to build a new type,
but I don't see how this new arrangement fixes the original problem:
- there's still a developer documentation issue about what you need to create to
add your own new thing
- it complicates things by requiring a new attribute/method lookup mechanism to
traverse the ActionItems and ObjectItem, or requires special lookup calls for
anyone who wants to use the them.
- it's not clear that the new generality would give us enough control to
implement Mimi's rules for how stamped types interact (that is, we'd still need
the same special-cases at stamping time).
- it doesn't solve the issues that Lisa brings up in the email thread, relating
to exporting of stamped items to iCalendar servers.
Hi Bryan. Have you looked at the stamping proof-of-concept in Spike yet?
http://cvs.osafoundation.org/viewcvs.cgi/internal/Spike/src/pim/content.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup
I think it should address at least your concerns regarding documentation and implementation complexity. It does, however, depend on Spike features that may not be portable to Chandler during the 0.6 timeframe. I'm currently working on a document that explains what Spike features I'll be attempting to port to Chandler, along with how they'll differ from those features as currently implemented in Spike, and how they'll differ from current APIs and practices in Chandler.
Btw, with respect to the export issue, my assumption was that the content/action model allows for stamps to be treated as independent items, and therefore provides a direction for resolving it. But perhaps Lisa can speak to what aspects are *not* solved.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
