Good, I'll try to do this before the end of this week. -----Original Message----- From: Davanum Srinivas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 5:56 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Again for explicitHeaderWork (Glen)
Sylvain, Please open a bugzilla enhancement request and post the latest cvs diff as attachment in bugzilla. Thanks, dims --- "St-Germain, Sylvain" <[EMAIL PROTECTED]> wrote: > > Feel good to see that you remember what was my point back then Glen. > > Although we should appreciate any contribution, implicit headers appears to > be much more in demand than explicit ones and this, no mater what the spec > says. IMNSHO, explicit headers should not prevent nor slow down the > introduction of implicit header support in Axis. > > The implementation I did is still in use here internally, we found some bugs > and fixed them locally, some more cleanup could/should be done. > > This being said, I reiterate my offer to contribute on the implicit side of > things. > +1 > > Sylvain. > > -----Original Message----- > From: Glen Daniels [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 08, 2002 9:36 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [VOTE] Again for explicitHeaderWork (Glen) > > > > Sorry I wasn't available earlier, there is no network connection available > from the interop - this means I also won't be around on Wednesday until late > in the afternoon. > > > This work contains: > > * Better rpc/literal support in the emitters and > > runtime...as described > > in previous notes. > > +1! > > > * Support to identify parameters and return values as > > header values. > > * Support in the serialization/deserialization to > > read/write values > > from the headers. > > * Some minor api additions to the Call object to identify > > parameters/return values as headers. > > -1... > > I still pretty strongly think that this is the wrong direction to be going > in. Headers are orthogonal extensions (remember "orthogonal > extensibility"?), and should be kept separate from the actual interface of a > generated component. > > All that is missing for basic support of headers through the stubs is > stub.addHeader()/clearHeaders() and something like > stub.getResponseMessage(), all of which would seem to be possible if we just > made the stubs have a 1-1 relationship with Calls. I talked to Sam about > this today at the interop; I haven't looked back through the archives, but > why aren't stubs associated with a single Call object and limited to use on > a single thread? It would seem making this fairly simple change would > enable a lot of the functionality people want re: setting/getting headers > via stubs, and wouldn't do it in a way that polluted the APIs of the > services. > > I think this approach also jibes with what Sylvain was trying to do a while > back. > > Then later we can talk about different ways of acheiving the same sort of > "syntactic sugar" that sticking the headers on the method APIs gives you. I > have some ideas on this, but I want to take things one step at a time. > > Thoughts? Apologies in advance for not being around during the day to > continue this discussion. If you want to check in the RPC/lit stuff, please > go for it, but my -1 on the header stuff stands. > > --Glen > > This message may contain privileged and/or confidential information. If you > have received this e-mail in error or are not the intended recipient, you > may not use, copy, disseminate or distribute it; do not open any > attachments, delete it immediately from your system and notify the sender > promptly by e-mail that you have done so. Thank you. ===== Davanum Srinivas - http://xml.apache.org/~dims/ __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
