Issues for Persistent Working Group of the CORBAservices RTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 26: Issue POS 2.0 RFP
Issue 27: Factory interface should be specified
Issue 28: PID additional attributes
Issue 29: PID attributes should be readonly
Issue 30: PID vs. OID definition
Issue 31: Typo in PID section
Issue 32: PID derivation
Issue 33: PIDFactory::create_PID* definitions
Issue 34: Returning PDS from PO::connect
Issue 35: PO::p attribute should be readonly
Issue 36: PO::connect and POM::connect exception needed
Issue 37: PO::disconnect and POM::disconnect parameters
Issue 38: PO::store/restore
Issue 39: PO::delete and POM::delete
Issue 40: SD interface
Issue 41: PDS_DA DDL should exclude type Any
Issue 42: PDS_DA::DAObjectID
Issue 43: Eliminate PID_DA definition
Issue 44: Support for DAObject interface

Issue 26: Issue POS 2.0 RFP (persistent)

Summary: TRC has found several issues that cannot be addressed within this forum and which would need to be addressed in a new POS 2.0 spec.

Summary: The Factory interfaces should be specified for all service component interfaces to provide for integration with the Lifecycle Service.

Summary: The PID should add attributes for the Datastore object reference and an opaque PersistentStateIdentifier. This allows maximum flexibility without the need to subclass the PID interface.

Summary: Attributes of the PID interface should be readonly and only settable through their initial creation by the PIDFactory and the service implementation.

Summary: The last sentence of para. 4 on pg. 5-9 is not implementable. How is the new storage allocation and location determined?

Summary: pg. 5-9, paragraph 6, remove extra p from "the ppersistent object..."

Summary: The PID interface derivation usage in the PID_DA and other examples in the specification limit the ability of the protocol to be decoupled from the datastore as intended.

Summary: The definition should not contain "...key that identifies a particular PID implementation." Overall these definitions contains a lot of confusion about PID identity.

Summary: The PDS reference should not be returned from the PO::connect operation, as this creates a number of implementation problems.

Summary: This attribute should simply reflect the currently connected PID, to avoid placing an additional burden on the PO implementation which is not needed.

Summary: An exception is needed to inform of an invalid connection (DDL type, protocol, etc.).

Summary: The PID parameter is extraneous, as the specification states that a PO can only have a single connection at a time.

Summary: Because para. 3, pg. 5-12 states that a PO can only have a single connection at a time, all behavior of these operations would need to be provided by the POM, which is difficult to do interoperably.

Summary: The delete operation should not have a PID parameter -- what does it mean if the PID specified is not the currently connected PID?

Summary: It is unclear how SD object implementations get intially connected to the POS implementation.

Summary: The inclusion of type Any in object definitions should be eliminated, because it makes schema evolution completely unmanageable.

Summary: typedef string DAObjectID should be typedef sequence<octet> DAObjectID. This will allow more flexibility in the PDS_DA implementation without breaking any functionality.

Summary: The definition for the PID_DA should be eliminated and the old attribute moved to the base PID definition. This will provide an invariant and abstract representation for all persistence state.

Summary: pg. 5-24, paragraph 1, section 5.10.2 states that "a data object is not require to support this interface." If so, there is not a way to free the storage for a data object or generate a PID.