thron7 wrote:
I would suggest that you create an RpcSoap directoory in
qooxdoo-contrib and put, at a minimum, a README file containing a link
to the soap project. That way, when people are looking for an RPC
implementation, they'll see it. All other RPC implementations in
qooxdoo-contrib are RpcSomething, so creating that directory and
readme will make it much more obvious.
I'm not so sure about that. If I got it right, Burak's Soap server needs
specific JavaScript Soap classes on the client side to talk to.
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.
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, 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?
burak
------------------------------------------------------------------------------
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
