On 7/2/07, Simon Nash <[EMAIL PROTECTED]> wrote:
I am reconsidering the changes made in stage 2 of this patch, which added two new methods to the Binding SPI interface. I made these changes for the reasons stated in http://www.mail-archive.com/[email protected]/msg19305.html and http://www.mail-archive.com/[email protected]/msg19308.html These methods allow bindings to be marked as either callback or forward bindings. This allows callback binding semantics to be supported correctly with relatively little change to the core runtime. Unfortunately these is a flip side to these benefits. Adding these methods changes the current published stable Binding SPI, and (probably worse) introduces "pollution" of the Binding SPI to carry information that is there for the convenience of the core runtime, rather than an intrinsic part of the binding semantics. The alternative is to keep the Binding SPI as it was, and make more extensive changes in the core runtime to use the more correct version of the model as proposed in http://www.mail-archive.com/[email protected]/msg19305.html I will look at the impact to the core runtime of the alternative approach that keeps the Binding SPI unchanged and I will post my findings back to this list. This discussion only affects the Binding SPI changes in stage 2 of the patch. It does not affect the provider SPI changes in stage 1 of the patch. I'd be interested in any comments on the above or on any other aspects of this patch.
It sounds good the binding SPI can remain unchanged, it also sounded like from the other thread that it should be possible to avoid some of the other SPI changes in "stage 1" as well which would be good. How about trying to get as much as this going with as few changes to the existing SPI as possible for now even if doing that requires some less then perfect code in the runtime impl and axis2 binding, and then once we have call backs and async working well with axis2 and ws-addressing and ideally at least another extension or two then look at what the best way to change the SPIs might be? There's a few other unrelated changes we probably need to do in the SPI as well, maybe we can save them all up and then have a single separate release specially for all these breaking changes and deprecate things so its really clear how/what/why things changed. ...ant
