Questions/issues for designing stamping content model

There's been some question about whether a stamped item is most like two items or one.

Design questions:

• Does a stamped item have two creation dates, or one?
• Does a stamped item always have one ACL, or can it have N?
• Is a stamped item always shared as a whole thing?
• Does a stamped item have one body or two?
  • With an email stamped as a task, the email body could become the body of the task-like stamped item. Or, the email body could remain the email body, and have a separate task body.
• Can you ever delete one aspect of a stamped item? Or is this "unstamping"?
• Can you ever separate a stamped item into two items?
• Does a stamped item have a single version history, or can you follow separate version histories for each aspect?
• Normally a task-stamped email shows up as a task. Does a search hit on the email aspect of a task-stamped email show up as a task too?

I think that the engineering decisions boil down to choosing, first, how the API appears to the API user (parcel developers), then how the underlying code is organized so as to make that API appear as designed. The most important choice to make for the API is probably how many objects the parcel developer has to handle to use a stamped item.

• One object: This could be a "monster" object that has all methods for email, tasks and events on it. (Of course, the monster object could actually be quite simple in implementation, delegating to internal objects not shown in the API. This is also called "bags of attributes" because it is the idea that an item can just have several bags of attributes on it.

• N objects: If a stamped item combines N aspects, then the API user deals with N items. So if an email is stamped as a task, there is an email object and a task object. They are tightly linked of course and displayed together to the user, but as an object model we have two separate API objects.

• N+1 objects: In this model there is an object for the "stamped item" as well as for each of its aspects. The API user asks the "stamped item" object for things like access control or date created, but asks the "stamped item" object for its email object or task object to get email or task specific methods.

Programmer questions:

• Are we going to use the same model for non-stamped items that we do for stamped items? Some models are appropriate for reuse for the simple case (the common case) of unstamped items.
• Rate each model for usability for Access control.
• Rate each model for how easy it is to deal with collections of stamped and unstamped items together. (membership/parentage)
• Rate each model for how easy it is to synchronize

-- LisaDusseault - 11 Jun 2004