[Dev] Re: Copypolicy override on Item instances?
donndenman at mac.com
Wed Aug 4 10:39:48 PDT 2004
I'm not using the old copy anywhere.
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?
> 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
>> 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
>> * 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 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
More information about the Dev