Hi Donn,
At a recent meeting with Morgen, Ted, Andi, Lisa and John, we decided to
depricate copy policy in the data model and to use item clouds instead.
Part of the reasoning for this decision is that we don't want to
proliferate a complex suite of policies to group items together (copy,
sharing, etc) that complicate the data model. We felt that item clouds
were going to be powerful enough for most of the situations where we
want to group items together into a larger logical item.
A few improvements to clouds are in the works, including simplified
parcel syntax, the ability to name a cloud, and a new "by method"
endpoint policy. We agreed that we are unlikely to be able to describe
every use case in a data driven fashion, and that in some instances
we'll need to write a bit of python to get the use case right.
So far we have these use cases for using cloud copy afaik:
* the events case you describe below
* instances of similar blocks in parcel xml (detail views, for example)
* creating a new item collection by copying an example or template
* copying of user data described in parcel xml to a separate user space
(not yet implemented)
I think the plan is to try out the new proposal on these use cases, and
see how it goes.
Cheers,
Katie
Donn Denman wrote:
> All,
>> I've been thinking a little about our CopyPolicy problem, and it seems
> to me that a simple solution would be to allow the copy policy to be an
> attribute of an /Item/ as well as a /Kind/. Then we can put a default
> policy on the Kind, and override it when needed for specific instances.
>> This solves the problems in the case that I've been thinking about the
> most: Events, and how they are referenced from block hierarchies. The
> way I see it, we have two kinds of events, global ones (which shouldn't
> be copied deeply) and block-specific events which should be cascade
> copied along with the block hierarchy. We could make the policy on
> BlockEvent Kind be 'cascade', so naive folks that don't specify a policy
> will get a deep copy of their block-specific events and everything will
> work for them. We'll identify the "Chandler Global" events like cut,
> copy, paste, open, close, etc and tag these individuals with a copy
> policy of 'copy'. This way we'll get a copy of the reference to the
> global event, but won't make a copy of that event.
>> I bring this up, in part, because Morgen is contemplating a shift to
> using Item Clouds for copy policy. As I understand them, Item Clouds are
> determined by the Kind, so they may not easily support an Item-based
> override of the copy policy. (I need to look at Item Clouds more
> closely, so I know the answer to this question).
>> John and Katie, what do you think of this idea of an Item override on
> copy policy? My gut feeling is that it won't solve all our copy
> problems, but gets us a lot farther without introducing very much of a
> complication to our existing model. I'd be interested in your feelings
> on this idea.
>> I'll follow up with Andi regarding the difficulty of implementation for
> an Item override.
>> - Donn