[Dev] Revisiting the stamping architecture

[Phillip J. Eby]

At 01:30 PM 04/10/2005 -0700, Bryan Stearns wrote:
>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 how
>>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.
>Rather than have a design discussion in bugzilla ;-), I'm reopening the 
>discussion here: Phillip, Lisa, Content-model folks -- your thoughts?


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.