Next in thread →
Next in month →
(no subject)
In other words, I see no advantage in having a producer fault a cloneBeforeWrite as it can just hold up the performBlockingInteraction, do an internal clone, re-target the performBlockingInteraction and return the handle of the new portlet. Can we identify a clear use case for the a producer being unable do the above before we complicate our protocol with another exceptional behaviour? regards, Andre -----Original Message----- From: Subbu Allamaraju [mailto:] Sent: 30 April 2004 04:18 To: Subject: Re: [wsrp-interop] cloning bahaviour Richard, > > Firstly, the Producer has a chance to > > make state changes. Secondly, with the interpretation you present, the > > consumer first makes a call with cloneBeforeWrite, gets a fault, clones, > > and then repeats the pbia. This is more work for the Consumer and more > > waiting time for the end user. > > Correct, but the spec allows that and might ease Producer implementations > and puts a burdon on the Consumer side (what we always did). > I agree that the spec places such burden in the case of session/cookie faults, but the spec was more explicit about those. But I still don't see the connection between StateChangeRequired fault and cloning from the consumer's perspective. What we need is perhaps a "CloneRequired" fault to unambiguously indicate that the consumer must clone and retry. Subbu To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_work group.php. ------_=_NextPart_001_01C42E86.D5D7DF2A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2657.88"> <TITLE>RE: [wsrp-interop] cloning bahaviour (SIC)</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2>From my recollections, the StateChangeRequired use = cases only supported readWrite and readOnly where a producer must be = able to signal that cloning is required. </FONT></P> <P><FONT SIZE=3D2>In other words, I see no advantage in having a = producer fault a cloneBeforeWrite as it can just hold up the = performBlockingInteraction, do an internal clone, re-target the = performBlockingInteraction and return the handle of the new = portlet.</FONT></P> <P><FONT SIZE=3D2>Can we identify a clear use case for the a producer = being unable do the above before we complicate our protocol with = another exceptional behaviour?</FONT></P> <P><FONT SIZE=3D2>regards,</FONT> <BR><FONT SIZE=3D2>Andre</FONT> </P> <P><FONT SIZE=3D2>-----Original Message-----</FONT> <BR><FONT SIZE=3D2>From: Subbu Allamaraju [<A = HREF=3D"mailto:">mailto:</A>]</FONT> <BR><FONT SIZE=3D2>Sent: 30 April 2004 04:18</FONT> <BR><FONT SIZE=3D2>To: </FONT> <BR><FONT SIZE=3D2>Subject: Re: [wsrp-interop] cloning bahaviour</FONT> </P> <BR> <P><FONT SIZE=3D2>Richard,</FONT> </P> <P><FONT SIZE=3D2>> > Firstly, the Producer has a chance = to</FONT> <BR><FONT SIZE=3D2>> > make state changes. Secondly, with = the interpretation you present, the</FONT> <BR><FONT SIZE=3D2>> > consumer first makes a call with = cloneBeforeWrite, gets a fault, clones,</FONT> <BR><FONT SIZE=3D2>> > and then repeats the pbia. This is = more work for the Consumer and more</FONT> <BR><FONT SIZE=3D2>> > waiting time for the end = user.</FONT> <BR><FONT SIZE=3D2>> </FONT> <BR><FONT SIZE=3D2>> Correct, but the spec allows that and might = ease Producer implementations</FONT> <BR><FONT SIZE=3D2>> and puts a burdon on the Consumer side (what we = always did).</FONT> <BR><FONT SIZE=3D2>></FONT> </P> <P><FONT SIZE=3D2>I agree that the spec places such burden in the case = of session/cookie </FONT> <BR><FONT SIZE=3D2>faults, but the spec was more explicit about = those.</FONT> </P> <P><FONT SIZE=3D2>But I still don't see the connection between = StateChangeRequired fault </FONT> <BR><FONT SIZE=3D2>and cloning from the consumer's perspective. What we = need is perhaps a </FONT> <BR><FONT SIZE=3D2>"CloneRequired" fault to unambiguously = indicate that the consumer must </FONT> <BR><FONT SIZE=3D2>clone and retry.</FONT> </P> <P><FONT SIZE=3D2>Subbu</FONT> </P> <BR> <P><FONT SIZE=3D2>To unsubscribe from this mailing list (and be removed = from the roster of the OASIS TC), go to <A = HREF=3D"http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/member= s/leave_workgroup.php" = TARGET=3D"_blank">http://www.oasis-open.org/apps/org/workgroup/wsrp-inte= rop/members/leave_workgroup.php</A>.</FONT></P> </BODY> </HTML> ------_=_NextPart_001_01C42E86.D5D7DF2A--
Next in thread →
Next in month →