axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Butek <bu...@us.ibm.com>
Subject RE: [VOTE] Again for explicitHeaderWork (Glen)
Date Wed, 09 Oct 2002 12:31:25 GMT




You guys just don't get it.  While I agree that explicit headers - headers
that are method parameters - are poor programming practice, WSDL 1.1
supports it, JAX-RPC defines how it works, and users (including interop
folks if I understand dims correctly, and WS-I) use it.  It is not our
place to enforce good programming style.  If we disagree with it we should
go to the spec folks.  But we MUST implement explicit headers!  Otherwise
we cease to comply with various specs out there.

Russell Butek
butek@us.ibm.com


Tom Jordahl <tomj@macromedia.com> on 10/08/2002 10:50:52 PM

Please respond to axis-dev@xml.apache.org

To:    "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
cc:
Subject:    RE: [VOTE] Again for explicitHeaderWork (Glen)




I am firmly in favor of a single Call object per stub.
I have always wished for the stub logic to be *much* simpler.
I think it is a reasonable requirement that stubs can't be shared
across threads.  I know that others might not.

I also like the idea of a setHeader/getHeader API on the Call.
I would think this would be a much more flexible design then
adding the headers to the functional signature.

Wouldn't the work be much simpler and more straightforward going this
direction?

--
Tom Jordahl


-----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



Mime
View raw message