axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "St-Germain, Sylvain" <Sylvain.StGerm...@cognos.com>
Subject RE: [VOTE] Again for explicitHeaderWork (Glen)
Date Wed, 09 Oct 2002 21:49:35 GMT

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:gdaniels@macromedia.com]
Sent: Tuesday, October 08, 2002 9:36 PM
To: 'axis-dev@xml.apache.org'
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.

Mime
View raw message