thron7 wrote:
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.
no worries.
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.
well, rpc is a hot topic nowadays, and i say supporting more than one
rpc protocol (or at least being prepared for it) would add value to an
application framework such as qooxdoo
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.
that's one of the reasons i'm insisting on bringing this up. even if you
don't want to include my soap contrib in the mainstream qooxdoo
package, you should be ready to do so *before* freezing the api.
eg. remember how it was VerticalBoxLayout and now it is layout.VBox ?
the same thing applies here, there has to be:
qx.io.rpc.Json,
qx.io.rpc.Soap,
qx.io.rpc.Xml etc.,
and not
qx.io.Rpc
qx.io.Soap
qx.io.XmlRpc etc.
i guess this point this merits an enhancement bug. i can file a bug
report if you think i should.
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.
i can say that this code doesn't derive from mateo casati's client
anymore, it's rewritten. there are code fragments here and there, but
the logic is completely different.
but as you say, at the end of the day, it just might not be enough.
the only suggestion i can make at this point is maybe you tell me what
you want to hear from the original author, i (or even you) can just ask him.
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.
well, as i did not get any feedback about the current state of the soap
api, i can't freeze it, and i won't write documentation for an unfrozen api.
as for the whitespace, the moment this code is reformatted to respect
qooxdoo style, it stops being my concern -- i despise qooxdoo coding
style. (seriously guys, are you using 16:9 monitors vertically or
something? i can see the frikkin "members : {" line, there's no point in
announcing it with an ugly 9-line comment block!)
HTH. Maybe Andreas can comment better on this.
thanks for your time thomas, appreciated. i now have a better image of
your expectations.
best regards,
burak
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
