Re: [regrep] PROPOSAL: More flexible ObjectRef

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Monica J. Martin wrote:

> Farrukh Najmi wrote:
>
>> Nikola Stojanovic wrote:
>>
>>> <Farrukh>
>>>
>>> > My proposal is to add a new logical id attribute to the set of
>>> > registry versioning attributes, and otherwise improving ObjectRef to
>>> > allow selection of a particular version of an object.
>>>
>>> +1 on being able to reference a logical object in a version independent
>>> manner.
>>>
>>> This is exactly what the lid attribute is for in the versioning spec
>>> being added to version 2.6.
>>>
>>> I think that the use case you raise can (and should) be addressed very
>>> easily by extending the ObjectRef class to have a choice of:
>>>
>>> a) a static "hard-wired" reference to a specific version of a specific
>>> object (current capability)
>>>
>>> b) a dynamic "late-binding" reference to a logical object which is
>>> determined at run-time (de-refence time).
>>> I could see this being done via a second attribute named "dynamic". 
>>> When
>>> dynamic is false (default) the registry
>>> assumes that the id attribute references the referenced object. When
>>> dynamic is true, the registry assumes that the id attribute MUST be 
>>> to a
>>> stored query that dynamically determines the referenced objects.
>>>
>>> This is a very powerful concept. Thanks Matt for seeding this idea. I
>>> hope we can discuss this over email prior to next telecon. Thanks.
>>>
>>> </Farrukh>
>>>
>>> I also see this as a very valid and a needed Use Case and that 
>>> LateBinding approach is interesting. However, I think that we have a 
>>> solution that doesn't need LateBinding. It would be something like 
>>> this:
>>>
>>> - subscribe to relevant event(s); in this case it is Update of the 
>>> objects that are members of the package.
>>>
>>> - implement "Web Service" that is going to be triggered by the above 
>>> event and that is going to adjust relevant object references.
>>>
>>> As one looks at the context of the two, LateBinding would incur 
>>> lookups whenever object references need to be resolved and 
>>> EventNotification will be invoked when relevant events happen. One 
>>> would assume that occurrence frequency of the first is higher then 
>>> of the second.
>>>
>> Interesting point that Matt's use case is already addressable via the 
>> Event Notification feature. So as I understand your suggestion the 
>> reference that needs to always be to the latest version of an object 
>> could be updated from one version  of an object to another by a web 
>> service that is an Event Notification Listener  service that gets 
>> invoked whenever a new version of the object is created.
>>
>> I agree with the point that your alternative is more efficient than 
>> late binding Object Reference approach and requires no additional work.
>>
>> I now reconsider the idea of doing late binding of object references 
>> now. Instead we should keep it in our future candidate work items and 
>> rely on your Event Notification based approach to address Matt's use 
>> case for now.
>>
>> Any one disagree with this proposed resolution?
>
>
> mm1: I don't disagree but wish to ask a question that applies to not 
> only late binding but the event notification approach where object 
> references are updated.  In ebBP, we found that LateBinding is not a 
> black-white situation. For example, when we started to talk about 
> conditional attributes such as time to perform, we determined that 
> LateBinding could have a duration, may or may not be allowed, and 
> constraints could be applied (when changed, if changed where does the 
> value come from, etc). This raises questions:
>
>    * Can you update the object references to the latest version?

Yes. For the latest object at the time of update.

>    * Are there conditions that apply? Are all objects in the package
>      updated?

Lets focus on the simpler case of Object A wishing to reference latest 
version of Object B.

The answer is that:

-If late binding is used then the object A updated when the object B is 
updated since the late binding ObjectRef stays unchanged.

-If event notification is used to update the reference in Object A then 
Object A will be updated (and likely new version created) when Object B 
is updated.

This is a significant difference between the two solutions.

>    * Does the owner define the duration, parameters or constraints of
>      when they can be changed?

Object B can change any time its owner (or delegate) updates it. Object 
A's owner (or delegate) controls the criterea for the dynamic reference 
but has no control over when Object B is updated.

>
> As well, in our work on time to perform, we found the conditional 
> aspects to be best expressed as an element not an attribute. 

In the late binding approach the conditional aspects are expressed in a 
stored query so an attribute with the query's id is sufficient.

Thanks for the though provoking questions.

-- 
Regards,
Farrukh