[Dev] Re: Copypolicy override on Item instances?
morgen at osafoundation.org
Tue Aug 3 22:49:17 PDT 2004
Just to follow up on this issue: I switched the parcel loader over to
using cloud-based copying, including the new 'byMethod' include policy.
An example of a 'byMethod' method is
osaf.framework.blocks.Block.BlockEvent.includePolicyMethod( ); it's
referenced in the Block kind's default cloud. That method determines
whether a BlockEvent should be copied by reference or by value on the
fly, based on the BlockEvent's repository path.
Unless anyone else is still using attribute-based copying, Andi should
potentially be able to deprecate it. Are we using attribute-based
On Jul 24, 2004, at 2:29 PM, Katie Capps Parlante wrote:
> 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
> 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.
> Donn Denman wrote:
>> 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
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2377 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20040803/356acae4/smime.bin
More information about the Dev