I think we agree that we can not generalize the Options for all the MEPClients. But If we are to have options we must compromise (at least on my view :) ) our client API.
My choice is keeping the Client API, but we are a team and I think everybody else agree on the other choice. So I will put 0- on it (In usual meaning, I am not sure.. but if the most of people belive it is correct please go ahead). Thanks Srinath On 11/30/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: > Hi Srinath, > > > 1) how about get methods for FaultTo and ReplyTo ect so that users can > > edit the EPR but make the address of the EPR final. Becouse once the > > user set a different ReplyTo address we should not start a listener > > and effectivly he is doing a one way. > > The problem is we can't do that with the Options approach .. then we'd > have to go back to getFaultTo etc. being on various MEP clients and > stubs. (Recall that Options is created independently and then hooked > onto a Call or whatever MEP client.) > > > 2) Do we have a real use case where the user want to set referance > > properties of Message when it is > > a) In-Out and > > b)Axis2 Handles the messaging > > c) It is not Policy decision (In case it should done by a handler) > > Yes absolutely. That's a way for the client to have any state its > interested in sent back to it when the server replies. Reference params > are the same as cookies, but unlike in HTTP cookies these suckers work > both ways. > > > Only thing I can think is user want the response to have a Header that > > Axis2 do not know about. In that case he can add a Handler and do > > that. Using referance property *unrelated to policy* is not a common > > case I guss. > > Asking users to write a handler so that they can insert a reference > property is unacceptable. > > > How about > > a) remove the set methods > > b) If ever someone ask to add a referance property via a ClientAPI, > > (where is common enough senario where asking him to add a handler is > > bad) lets add get methods. > > -1 for the reasons above! > > > I am fighting for this becouse once user set a replyTo with a > > different address it become In-Only in client point of view. (we > > should not start a listener) in which case he should be using > > In-OnlyMEPClient. If we need a one guy who do everthing lets get rid > > of the In-Only Mep client have a one MEPCleint for all. By letting > > user change the ReplyTo address we make the InOutMEPcleint a > > InOnlyMEPClient and breaking major archtectural principal on the > > initial decision ( at least I see it that way :) ). > > My thinking is along the lines of "we only build the gun, you shoot it." > We can (and will) document the perils of being sloppy with the address > field of ReplyTo and FaultTo but I don't want to disallow users from > setting it because it does have its usages. So let's go with and put big > blinking warnings! > > Sanjiva. > > >
