Burak, you created the rpclib fork to support your vision for a generic RPC library, right?
Meanwhile, soaplib should focus on providing a stable, well-tested, well-documented SOAP-compliant server for the Python community. Trying to support generic RPC cases might be a distraction from the basic mission of supporting the SOAP specification. I agree that we might want to add support for SOAP 1.2 at some point in the future, but that is too big a project for the soaplib 2.0 release (which is very close to final right now). On Mon, May 23, 2011 at 11:19 AM, Chris Austin <[email protected]> wrote: > Welcome back Burak, > > I tend to prefer the latter approach. But, before we start looking at > merging the code from rpclib's soap components there some real > structural changes that I are needed in soaplib. In particular, there > is a lot of tight coupling between a lot of the core classes and > _base.Application knows way too much about other classes. Minor stuff > in the scheme of things but I hate breaking the api to often. > > But sure, lets do what we can and make this work. > > On Sat, May 21, 2011 at 9:36 AM, Burak Arslan > <[email protected]> wrote: >> >> hello everyone, >> >> i found myself with some free time on my hands, and plan to hack rpclib >> some more. >> >> i've been looking into the work that went into soaplib in the past >> months and applying the changes as i go along to the rpclib codebase. >> wasn't so hard so far. >> >> as you might remember, the promise of soaplib-3.0 was to support >> multiple soap/wsdl versions. while doing that i'd realised that it'd >> became trivial to add other protocols, so i went forward and added them, >> which rendered the soaplib name rather inappropriate. so i renamed the >> package to rpclib and just when i finished the job, i had to go offline >> abruptly for some time. >> >> now that i'm back, i see that we ended up with two soap codebases. i >> think (and i'm sure you'll agree) that this town is too big for both of >> them. >> >> so, after i go over all of your changes, i see two ways forward: >> >> 1) you guys drop soaplib and work on soap parts of rpclib. >> 2) i remove soap code from rpclib and use soap logic from soaplib. to do >> that you'd have to redo part of what i did for soaplib to support the >> new protocol api, so that i can wrap soaplib code inside rpclib. >> >> why should you care? >> if ever you'll want to support multiple soap versions inside one soaplib >> package, you'll have to redo what i did for soaplib to become rpclib. if >> you're confident that you'll be happy forever with soap/wsdl 1.1 pairs, >> you can just ignore me. >> >> so, what do we do now? >> >> best, >> burak >> _______________________________________________ >> Soap mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/soap >> > _______________________________________________ > Soap mailing list > [email protected] > http://mail.python.org/mailman/listinfo/soap > _______________________________________________ Soap mailing list [email protected] http://mail.python.org/mailman/listinfo/soap
