Implementation Considerations

Handles in Path Arguments

All routines which take a CaList in order to provide a path specification to the driver must be able to accept a handle as the first element of this list.

A handle is a unique reference to access the object. If the object becomes unavailable due to a __cb_put__ or __cb_delete__ operation, it must remain available through all active handles. Handles are provided to allow applications to skip processing of the Casbah Virtual Namespace and jump directly to an object, as well as to ensure that they can access it at a subsequent point. An object handle must be unique both in the object space and in time. [1].

Whenever a Natroun driver is invoked by another Natroun driver, the invoking Natroun driver must provide an object handle to the called Natroun driver. For example, NatrounFS calls NatrounXMLDoc to process a __cb_get__ call for an item inside of an instance of NatrounXMLDoc. NatrounFS must create an object handle for the NatrounXMLDoc instance and pass that to NatrounXMLDoc, thereby allowing NatrounXMLDoc to access itself.

The exact mechanism of passing this handle is not specified by this document at this time.. One possible method would be to have Cairo Public Interface provide a handle stack which the calling Natroun driver must push the handle onto. The called Natroun driver merely needs to check the last element; it would not pop the handle off of the stack. This allows a scan back up the "call" stack to some extent. The Natroun drivers should also push on the path of the called Natroun driver, in the calling Natroun driver's namespace. If these paths are joined together a Natroun driver would get the location of itself in the Casbah Virtual Namespace.