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
