[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles
If there is no personalization or configuration possible on the entity, then why would the Consumer want to call cloneEntity in the first place? Seems to me it should just be using the POE handle. The protocol issue here is not only one of correctness, as Rich points out, but efficiency. -----Original Message----- From: Tamari, Yossi [mailto:yossi.tamari@sap.com] Sent: Wednesday, October 09, 2002 9:07 AM To: 'wsrp-wsia@lists.oasis-open.org' Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles Hi Rich, I also think we have a misunderstanding. Let me describe the flow: 1. The consumer wants a clone. 2. The producer says to itself: "I am a very simple producer. I have no personalization or configuration information. I would have no data to hang off of the new copy. The two copies will be identical from my point of view. Let me just return ME as a copy of myself". 3. The consumer receives a handle. It is the same handle that was sent to the cloneEntity operation but the consumer shouldn't care (except perhaps to recognize it and append a GUID if it really wants this to be unique for internal purposes). 4. In consequent operations the consumer sends the same handle to the producer again. Of course, the same results will be returned no matter which of the two handles it used, since they are the same. However, this is the desired behavior for this portlet, as defined by the producer. Yossi. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, October 09, 2002 5:40 PM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles I think we may be confusing two issues here: 1) Due to the way a Consumer wishes to use an entity, it determines it needs a clone 2) Due to the way a Producer hosts an entity (or the details of the registration, etc), it determines that an entity may not be cloned The second covers the semantics you are talking about. From my point of view, if the Consumer has determined it needs a clone then any failure to produce such a clone needs appropriate error processing. From the protocol point of view, how could it not be an error for cloneEntity() to fail to produce a clone? "Tamari, Yossi" <yossi.tamari@sap To: wsrp-wsia@lists.oasis-open.org .com> cc: Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles 10/09/2002 11:10 AM I disagree. The semantics I am referring to are that there is no need to clone because the entity has no state. Only the producer knows this, and the producer DOES know this. This is NOT an error. Furthermore, the consumer doesn't care about this. From its point of view this is a new entity. The only issue here is that the consumer may run into problems if it uses the handle as a key. We already saw other places where using this handle as key limits the protocol, so maybe this is not a very good idea. This is why I don't think we should throw an exception, and if we do, it should be a clearly defined exception that does not denote an error. Yossi. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, October 09, 2002 4:20 PM To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles But the Producer can not say that a clone was not needed, only that a clone is not possible. If it is not possible and the operation is cloneEntity(), then that is an error. "Tamari, Yossi" <yossi.tamari@sap To: wsrp-wsia@lists.oasis-open.org .com> cc: Subject: RE: [wsrp-wsia] [I#106] Uniqueness of entityHandles 10/09/2002 08:54 AM This seems to send the wrong message. My view on this is that no error happened. It is simply that a copy operation was not needed. Yossi. -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Wednesday, October 09, 2002 2:51 PM To: wsrp-wsia@lists.oasis-open.org 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> ---------------------------------------------------------------- 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