[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
My preference would be a fault message that says "Entity Not Clonable". It returns no handle, but explicitly says that the clone failed. Andre Kramer <andre.kramer@eu. To: wsrp-wsia@lists.oasis-open.org citrix.com> cc: Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles 10/09/2002 08:42 AM A fault would be better. But is it possible to return Handle A multiple times for getClone(X) where A <> X? (I would hate to have to go inside a fault message to get the actual returned handle.) If it is always a new handle or the handle being cloned then we could just allow a null return to indicate that: - no error occurred - no clone was required -- Andre -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: 09 October 2002 13:06 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles Another way, which is less weird and more explicit is that in the case a Producer receives a cloneEntity which is of a type that the clone is not different than the original, then the Producer _faults_ to indicate to the Consumer - "look, this clone is useless - go ahead and use the original". Gil -----Original Message----- From: Andre Kramer [mailto:andre.kramer@eu.citrix.com] Sent: Wed, October 09, 2002 13:57 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles I still find this a bit strange. Maybe the operation should then be called "customizeEntity" rather than "cloneEntity"? -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: 09 October 2002 12:17 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles I agree with Yossi, and I think my previous reply solved the problem conceptually, so I'll copy it here: It's not that cloneEntity returns a new entity with the same handle, it's that it returns the same entity (and thus the same handle). What the spec should say in this case, is that the "cloneEntity CAN return the same entity in case there is no provider-side difference between the two". Thus we get back to the entity <==> handle. Gil -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sap.com] Sent: Wed, October 09, 2002 13:00 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles Or the consumer could attach a GUID to the returned handle and then remove it before sending the handle back to the producer. Why put the load of making the life of a specific consumer implementation on every producer? Yossi. -----Original Message----- From: Andre Kramer [mailto:andre.kramer@eu.citrix.com] Sent: Wednesday, October 09, 2002 11:29 AM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles This could get very confusing for consumers as they should be allowed to test for equality by comparing handles? For your example, the producer could append a large random number (impacting handle size) on clone and strip it off when receiving the handle back to make handles appear unique. regards, Andre -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sap.com] Sent: 09 October 2002 10:15 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles While Gil is obviously correct in theory, it might useful in practice to allow a producer to return the same handle as a result of CloneEntity. If this entity has no persistence, there doesn't seem to be a need for a different handle, and it removes the need for this simple producer of dealing with multiple entityHandles. Yossi. -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: Wednesday, October 09, 2002 6:41 AM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles How can it be other than a MUST? If two entities have the same handle, then they are, by definition, the same entity. This is not even a MUST - it is evident by the very nature of the definition of a handle as a unique identifier of something. -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: Wed, October 09, 2002 06:38 To: wsrp-wsia@lists.oasis-open.org Subject: [wsrp-wsia] [I#106] Uniqueness of entityHandles Topic: Interface Class: Technical Raised by: Rich Thompson Title: Uniqueness of entityHandles Date Added: 9-Oct-2002 Document Section: Interfaces/6 Description: Do we want a statement about uniqueness of entity handles within the scope of a registration? Would it be a SHOULD or a MUST? ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC