> > well, the first ever port of soap client was pretty bad. but with my > recent rewriting of the client, it got as standards conformant as i > could make it to be (the soap standard is huge, and i'd appreciate > more testing). yes in a sense you're right, you need a specific > client. but don't forget that soap is a w3c standard and not just some > protocol i came up with.
I didn't want to belittle your Soap implementation, I hope you didn't have that impression. I just wanted to make that distinction so people don't confuse things. I think the work done around the Json RPC (if we may call it like that), both on the client and the server side, is very valuable and seems to have evolved into a "main road" of communicating with the server for a qooxdoo app. So we should keep that environment straight. But that shouldn't depreciate other transport mechanisms, just set them clearer apart. >> So, if I >> got that right, it doesn't fit straight in the row of backends that work >> interchangeably with the standard qooxdoo RPC client classes. I think >> the Soap contrib is an *alternative* transport mechanism, and adding a >> RpcSoap contrib would actually mislead people in believing that would >> work with vanilla qooxdoo RPC classes. >> >> > > if ever qooxdoo devs choose to include soap client inside mainstream > qooxdoo, this problem vanishes :) (i'd raised the point of including > soap client inside mainstream qooxdoo, I remember that much. > but it got forgotten, see one of my soap client announcement mails) so > what do qooxdoo devs think about including my soap client in > mainstream qooxdoo distribution? I can only give you my personal 2 cent. There is, AFAIK, currently no established process by which contrib projects are evaluated for inclusion in the framework. My best suggestion would be to open an enhancement bug for this. This will feed the issue into our workflow and keep it on our radar. Also, others can comment and vote. But that doesn't automatically mean it will happen any time soon. As we are heading for the 1.0 release this year, much attention will be given to API and runtime stability, and there are probably other API changes in the queue already that will be given higher priority. Besides that, there are things to consider. I see there might be some concern about licensing issues with your contrib, which is critical for qooxdoo. Your client uses third-party code from codeplex.com which is GPL-ed, and the hand-waving attitude of the original author in a personal mail to you might not be enough at the end of the day. Also, there seems a bit of work open on the code level, assimilating your code to qooxdoo name spaces, documentation and coding styles. E.g. your code should fit seamlessly into the qx.io name space (e.g. as qx.io.Soap), together with the proper Apiviewer documentation, headers, whitespace and whatnot. The contrib's soapdemo name space and the contained modules don't resemble that very much. This is something you could work on. Eventually, when it comes to evaluation it should be easy for the core team to "see" how your modules would fit into the framework, both from a structural, coding-style and functional point of view. HTH. Maybe Andreas can comment better on this. T. ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
