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

["David W. Forslund" <dwf@lanl.gov>]

At 05:14 PM 3/19/99 , Charles Carman wrote:
>Dave,
>
>Additional points need to be made here.  In the current COAS IDL,
>ObservationIDs are returned as ObservationQualifiers.  They are returned

This isn't obvious from the IDL.


>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.

But you seem to allow for ObservationRemote (BrowseAccess) for everything,
thus I can get an
Object reference which is all I need.  I just need a way to control or
steer it.  It isn't obvious that ObservationId 
wouldn't be supported by most servers since it is in many of the Access
calls.  I actually think an ObservationRemote interface is preferable.

>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.

In the other email I tried to describe it.  We may have attachments that
could be "heavyweight" (e.g., images)  and not desirable to be send in a
query, but would be fetched in a deferred manner.  Having those attachments
returned as ObservationRemote interfaces would be nice (and thus legal to
have in the Any for ObservationValue as I understand). 
The same applies for an ImageStudy, for which we would like to obtain a
reference from the Query and then start the BrowseAccess process.

It could be considered a performance question, but it is more than that I
believe.  If it is acceptable to return an ObservationRemote interface in
the any of ObservationData and this can be "selected" by means of a POLICY
directive, the problem would be taken care of.  Since you have two
"multimedia" types in ObservationValue now, it only needs to be stated that
an ObservationRemote is also legal and that a mechanism as indicated by
Larry would be the way to declare that you want to have a reference not the
entire data.

The Use case is a clinician trying to review the various treatments and
reports on a patient and wanting to only see the "supporting" information
such as imagestudies or attachments if they need it, but would like to know
that the information exists.

Thanks,

Dave 
>
>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
>>