[Dev] Re: Copypolicy override on Item instances?

[Donn Denman]

I'm not using the old copy anywhere.

-Donn

On Aug 3, 2004, at 10:49 PM, Morgen Sagen wrote:

>
> 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
>>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev