Hi Burak, Le 10/12/2011 12:34, Burak Arslan a écrit : > > Hi Christophe, > > Thank you very much for responding. > > On 12/08/11 13:37, Christophe de Vienne wrote: >> Hello, >> >> I am the author of http://packages.python.org/WSME/. >> >> The original goal of this project is to write a better TGWebServices, >> while keeping a very similar (if not identical) API. >> The "better" things I needed were : >> >> * Batch calls (for the ExtDirect implementation which is the one I >> am using the most the this time, and also for json-rpc which will >> come sooner or later). >> > > How do you support batching with soap? Soap the protocol does not > support batching as far as i know. (i.e. soap:Body has max_occurs=1 in > the soap 1.1 schema) I support it the simplest way : I don't.
Batch calls are implemented only in the protocols that supports it. Right now ExtDirect, and later json-rpc. And they come with their load of problems, most notably the response status code handling (and errors generally speaking) and the transaction handling. >> * Extendible type system >> > can you elaborate on that? both rpclib and ladon support extensible > types one way or the other. In a few words : User can define its own complex types, as well as defining how custom simple types should be encoded/decoded, even in a very specific way for some protocols thanks to simplegeneric (not documented yet). A detailed explanation of the type system is available here : http://packages.python.org/WSME/types.html >> * Take the protocol implementations out of the core API so that >> they can be safely tweaked >> > > again, these are one of the major features of both rpclib and ladon. > or am i misunderstanding something? Well, I was underlining the improvements over TGWebServices, not the differences with rpclib or ladon which I do not know well enough. Based on what you say though, I think I should have better to them to either pick ideas or stop doing extra work ^^. However note that the first feature of WSME is to be an almost drop-in replacement for TGWebServices (only renaming the decorators is enough for most of the code, and otherwise a few changes on how the api gets published). >> * Portability to TG2 without rewriting everything like I had to do >> for http://pypi.python.org/pypi/TGWebServices/2.0.0a2 >> > > I can't comment on this as i'm not familiar with turbogears. here's a > django wrapper for rpclib: > https://gist.github.com/1242760 Would writing a tg wrapper be much > more work than this? Probably not : it would be about the same complexity. But I intend to add is the possibility to use the @requires decorators of TG inside the WSME tree. I don't know if it is easy to do, I did not have a look yet. >> The bonus of this rewrite was to remove completely the TG requirement. >> >> Note that only a subset of each protocol is generally implemented, >> the one that is necessary to expose the API. >> > > Oh especially with soap, that's how it works almost everywhere :) Server-side it is a sane approach. Client-side is another story. Cheers, Christophe
_______________________________________________ Soap mailing list [email protected] http://mail.python.org/mailman/listinfo/soap
