[Cosmo-dev] Stamping Model Concerns

[Randy Letness]

Ted Leung wrote:
>
> I understand the rationale for the various Stamp classes, especially 
> since most of the stamps introduce new behavior, and there's no way to 
> get that new behavior without code - that is classes.  This is also 
> what happens in Chandler.    What I'm less excited about is the need 
> for separate tables for the various stamps.   That doesn't correspond 
> to what happens on the desktop, but slavish copying of the desktop 
> implementation is not a requirement.   Right now, I don't think we 
> know whether new stamp types or new item types will be a more 
> prevalent form of extension in Chandler.

Actually new stamp types may not require a new table.  You can store 
stamp data as item attributes, which is how Chandler does things.  The 
Stamp wraps an Item.  Calling FooStamp.getFooVal() would map to 
Item.getAttribute(FooStamp.fooVal).  This probably needs some Hibernate 
mapping changes, but I think you can do this.  The disadvantage is that 
you don't have as much control of the data (how its 
indexed/validated/etc) as you would with a separate table with separate 
fields.

> I thought that Cosmo was already persisting things like jpgs that were 
> shared up from Chandler.   Does cosmo just treat that data as blobs 
> without meaning?
Cosmo can persist jpegs if they are sent via DAV.

-Randy