[Dev] Re: Copypolicy override on Item instances?

[Morgen Sagen]

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 
copying anywhere?

~morgen

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 
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2377 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20040803/356acae4/smime.bin