Re: [COAS-List] moving between QueryAccess and BrowseAccess

[Charles Carman <ccarman@medgrid.philips.com>]

Dave,

Additional points need to be made here.  In the current COAS IDL,
ObservationIDs are returned as ObservationQualifiers.  They are returned
this way because we did not want to require an ObservationID for every
ObservationData object in the hierarchy, nor did we believe that all
ObservationData objects should have unique IDs.  Our current "model" (only
in some of our heads) is that most servers will have unique IDs for only
the ROOT ObservationData objects.  Thus, your proposed use of COAS may not
be supported by some (many?) COAS servers if you expect that an
ObservationID will be available for any arbitrary ObservationData object in
the data hierarchy.
To help us understand your situation and respond with particular examples
or suggestions, would you please explain the use-case/example you have in
mind?  There are certainly uses of COAS that we have not anticipated.

Thanks for your help working out these kinds of details!

Chuck Carman

At 03:47 PM 3/19/99 -0800, Larry Hamel wrote:
>Dave,
>
>>
>>Also,  a limitation we are seeing (perhaps it is a lack of understanding of
>>some functionality) is the inability to move between the QueryAccess and
>>BrowseAccess.  It would be nice to do a constrained QueryAccess and then
>>resume the Access with a BrowseAccess below the point that was constrained.
>> It seems that this would require returning a ObservationId or a
>>RemoteObservation at the leaves of the ObservationData returned from the
>>QueryAccess.  That is it would be nice to have a RemoteObservation
>>interface as legitimate ObservationValue.  This is recognized in Multimedia
>>interface and in the CurveIterator, but we see a more general need to be
>>able to not return everything in the queryaccess and pick up from one of
>>the points and do a browseaccess.  We don't see any way to control this
>>properly otherwise.  Not just a specific multimedia interface is the only
>>thing needed to return an interface.  Ideally this should be able to be
>>controlled either by a policy or by a qualifier.  I dont' see anywhere that
>>ObservationId is returned on a call and it is the only mechanism I can see
>>to move between browseaccess and queryaccess.
>>
>
>
>hmm, good question.  i never thought of moving between access metaphors
>like that, but i think there are ways to accomplish this in the current
>interface.  
>
>as you say, the ObservationId method seems straightforward: use QueryAccess
>to where you want to start browsing, and then use an ObservationId from
>there to start browsing with BrowseAccess.get_observation(id).
>
>there are several ways you can eliminate a step, all based on one key: an
>object reference can be returned within an Any.  
>
>one ugly way would be to create a new QualifiedCode for the thing you want
>remotely, say a "Foo", which would be "Foo_Remote" which tells the
>QueryAccess to return, within the Any, just the remote object reference you
>want.
>
>a better way might be to invent a Policy for this remoteness, say,
>RETURN_REMOTE_OBSERVATION_REFERENCE_POLICY, which signals the server to
>return a remote reference for the given object, within the Any.  use
>Any.extract_Object() to get the object reference out, and narrow it
>appropriately.  
>
>can you answer a question for me?  in what scenario do you anticipate using
>BrowseAccess?  beware that a server offering this component must handle the
>lifecycles of many relatively fine-grained objects, in the face of
>potential traumatic termination of clients (and ill-behaved clients).    
>
>larry
>