[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[COAS-List] moving between QueryAccess and BrowseAccess



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