Re: [regrep] PROPOSAL: More flexible ObjectRef

["Monica J. Martin" <Monica.Martin@Sun.COM>]

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?
    * Are there conditions that apply? Are all objects in the package
      updated?
    * Does the owner define the duration, parameters or constraints of
      when they can be changed?

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