On Mon, May 23, 2011 at 2:52 PM, Brad Allen <[email protected]> wrote:
> 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. > > Completely agree, until get well-tested server IMHO project dont need to merge with another issues, it does not means can exists a fork about rpc-soap and can maintain who will merge in a near future his project. Regards, > 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 > -- Cristian Salamea @ovnicraft
_______________________________________________ Soap mailing list [email protected] http://mail.python.org/mailman/listinfo/soap
