[Cosmo-dev] Stamping Model Concerns
twl at osafoundation.org
Thu Nov 30 18:29:13 PST 2006
On Nov 29, 2006, at 6:15 PM, Randy Letness wrote:
> Bobby Rullo wrote:
>> I know that we are only supporting a very limited # of stamp types
>> for Preview, but surely we want to storage of arbitrary data with
>> stamp types that a particular Cosmo server has never encountered.
>> The way things are now new tables and classes would (it seems)
>> have to be added, which doesn't seem like a very good solution.
> Yep, new stamp types that Cosmo needs to understand would require a
> new class and table. We can persist arbitrary data using Item
> attributes, but if Cosmo needs to do anything special with the
> data then its better to break that data out into separate tables
> where you can optimize indexing ,storage, and retrieval based on
> the type of data. Also, new stamp types are only part of it. What
> about new Item types? Currently the Chandler model has ContentItem
> and a few stamp types, but you could also define a new Item type.
> Cosmo doesn't have a way to persist arbitrary Item types.
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.
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?
> Also, theres a trade off when deciding how abstract you want your
> storage model to be. The more abstract, the more overhead
> (performance hit) required. Chandler has a pretty abstract way of
> storing things but then again its a single user app and Cosmo needs
> to support potentially thousands of users.
I'd strike the word potentially in your last sentence...
More information about the cosmo-dev