[Cosmo-dev] Cosmo 0.6 object model changes

[Randy Letness]

Brian Moseley wrote:
> - what will namespaces look like? who will define them - the protocol
> client? the server protocol implementation? the model?
>

I'm guessing all of the above.  For DAV, the client will define them.  
There may also be model defined namespaces for storing attributes as 
part of a stamp.  I hadn't really thought of what they will look like.  
For stamps, they could be a class name like 
"org.osaf.cosmo.model.EventStamp".
> - Item should probably have a Set<Attribute> getAttributes(String
> namespace) method to get all attributes for a specific namespace
>

Yeah good idea.

> - (the hard one) what do we do about icalendar data that isn't
> represented in one of the stamp tables?
>

That is the hard question to answer.  We really want to support all of 
icalendar right?  For 0.6 we could stick with storing and indexing the 
icalendar blob.  That would keep queries fast and require minimal 
changes to existing code.  Another option is to store the icalendar 
attributes as flattened key/value pairs (need to be ordered) like we do 
now in the calendar attribute indexes.  I don't see much benefit to this 
as we will most likely have read all the data into an ical4j Calendar 
object for manipulation and rewrite everything for an update.  It does 
save space though.  By storing the blob, we don't have to worry about 
limits on attribute names/values (like we do on the indexes).  Coming up 
with a full icalendar schema is doable but seems a bit much, considering 
the time we have.  The EventStamp should encapsulate all of this, so 
maybe for 0.6 we stick with a simpler solution and revisit later.

> - how do stamps relate to a ContentItem's content? in other words, if
> chandler publishes a stamped Item to us, does that Item not have any
> content? is it even a ContentItem?
>

I see two types of ContentItems.  One is a file published using DAV.  In 
this case, a ContentItem is created, and the file is stored as the 
content.  Chandler will never see these ContentItems as they are not 
stamped.  If CalDAV is used, then no content is stored.  Instead, an 
EventStamp is created.  Chandler will see this item on a 
subscribe/sync.  A DAV request on a ContentItem with an EventStamp would 
use the stamp data to return the .ics content.  I guess that brings up 
the question of what happens when there is a DAV PUT to an existing 
ContentItem created by Chandler (overwrite event with a .jpg or 
something)?  Is that ContentItem overwritten, or should an error be 
returned?  This may never happen.

> - for multistamped items accessed with caldav, perhaps we define an
> order of precedence for stamps? perhaps event > task > note. then we
> return the icalendar component corresponding to the highest precedence
> stamp.
>
Seems like a good idea.  I guess you only really benefit from 
multi-stamped items if using Chandler or Cosmo UI.  Maybe we could use a 
query param to override this.

-Randy