conversation about stamping with alec and bryan

low level problems that a "loose coupling" implementation might help with

• stamping and unstamping loses information
• overlapping attributes
• recurrence is nasty
• personal "annotations" that are not shared
• 2 layers -- the implementor has to choose between them, some other layer has to work with either or both
• items are already a network of items -- look at location. contacts/address book is going to force this issue as well.

motivators for "identity model" of stamping

• search results turn up one item (and may be more effcient if you don't have to traverse linked items)
• from an api perspective you want to link to the "whole item" -- how do you choose which linked thing?
• you want to share the whole item (of course clouds address this)

clouds may be a mechanism for addressing "whole item" issues in general

email and stamping

• concern that we are throwing away information if we update the "main" item every time a new email comes in
• how is it that we are viewing the chatter emails? if communications stamp is different from underlying email, are emails content items? do they display in the detail view? do we write specific code to display them?

annotations?

• adapter pattern does make sense
• reminds alec of zope interfaces
• problem: you do need to know what context you are looking at

context

• calendar app area is a context. the calendar app area knows about calendar events, it assumes the things it is viewing are all events, all have start times or some other attribute that is found on "calendar event"