On 8/10/05, Glen Daniels <[EMAIL PROTECTED]> wrote: > Hi all! > > Sorry I'm a little late to this discussion...
not late at all: still at the idea stage. > Sanjiva Weerawarana wrote: > > On Tue, 2005-08-09 at 20:51 +0100, robert burrell donkin wrote: > > > >>i've been wonder whether it might not be easier and quicker to use an > >>existing dynamic start-from-java binder. a lot of progress has been > >>made in the last year or so on these. i suspect that it might be > >>possible to attract developers from outside the core axis team to do > >>the coding (though probably some help with design would be needed) and > >>so free up some core axis committer time. might make some sense in the > >>medium term as well: one less non-core technology for the axis team to > >>support but... > > Robert - can you give me an example? Are you talking about packages > like Beck (http://beck.sourceforge.net/)? yep but the one i had in mind was xstream (http://xstream.codehaus.org). it's under pretty active development (so i had hoped we might be able to talk them into help out) and seems like it might be a reasonable match technology-wise. > >>i guess whether it's worth it depends on how much work's already been > >>done and how close it is to being finished... > > I've got some framework in my sandbox which I'll commit after 0.91 goes > out. It's indeed fairly like some of the stuff in Axis1, with a > DeserializationContext and a SerializationContext which keep track of > multirefs, an RPC MessageReciever which knows how to turn > <method><arg1/><arg2/></method> into a call to method(arg1, arg2), > simple serialization/deserialization framework based on the typemappers, etc cool the serialization and deserialization bits could be replaced by a more expressive db than that in axis one. i suspect that it might be possible to port the old typemappers over to xstream relatively easily but this would need further investigation (if it sounds like a plan)... alternatively, the stuff you have already could be wrapped in objects and mapped at the top level. (i like the idea a pure document protocol with rpc being supported by the binding but i'm unsure how good that would be in practice...) > It's not that close to being finished yet, though. > > > Actually, even if Glen's doing an "old style" data binder, I would say > > that does not in any way preclude doing a dynamic start-from-java binder > > in any way. If yours comes out better we can figure out how to make it > > be default. > > +1. Let's continue discussion, and Robert and others can take a look at > where I'm headed once I commit. cool. from what i can see, the bits glen has already seem to me to be the bits that would be need to be written (in addition to the db) in any case. what i would like to do sometime soon is to contact the xstream team and see what they think of the idea (unless there are anyone out there who'd like to jump in here now ;) opinions? > > Also, IIUC Glen's working on the simple type stuff to make rpc/lit type > > stuff work nicely for simple typed parts. Right now the XMLBeans stuff > > does everything but if you give a simple type you get ugly stuff- so > > he's working to fix that so "String echoStr (String)" can be generated. > > Correct. Whatever "simple" db framework we include must be able to: > > 1) Do rpc/lit AND rpc/enc > > 2) Handle WSDL 1.1 "wrapped" style method calls > > 3) Handle SOAP 1.1 and SOAP 1.2 data encoding (arrays, mrefs) > > 4) Handle WSDL 2.0 RPC style (once we're handling WSDL 2.0 :)) you're right: seems like the framework won't be that simple. i'll use 'old style' in future :) but it's just binding and nearly anything is possible with enough effort. the question is how easy those thing would be to do (and how many hands there'd be to help). i don't know enough about xstream to give a good idea of that... > It would be nice if the framework could handle pulling the XML events > during deserialization in such a way that no OM caching needs to be done > (a little tricky when multirefs are involved). AIUI xstream uses pull parsing (which is one of the reasons i thought it a good match) but i the devil will be in the detail of the framework... - robert
