[Xml-compile] XML::Compile::SOAP and PSGI

[Chris Andrews]

On Wed, Jan 19, 2011 at 1:39 PM, Mark Overmeer <solutions at overmeer.net> wrote:
> In 3.00, the following modules have emerged:
>
>   XML/Compile/SOAP/Daemon/LWPutil.pm
>   XML/Compile/SOAP/Daemon/NetServer.pm
>   XML/Compile/SOAP/Daemon/CGI.pm
>
> The ::Daemon::NetServer is a rename of ::HTTPDaemon.  The "old"
> HTTPDaemon was based on a Net::Server daemon implementation, not
> on the HTTP::Daemon of LWP.  The parts of LWP which where used
> got abstracted into LWPUtil which is also used by CGI. It should
> suffice to base your implementation on ::Daemon.

Oh, excellent. There is plenty in the HTTPDaemon base class which I
have no need of in PSGI.

> You offer people a wsdl_file parameter. That's insufficient: many
> WSDLs require additional XSDs, hooks etc.  So, at least there
> should also be a way to pass in a prepared wsdl object.

That makes sense, and it's trivial to do.

> On a few spots, I see that you dive into the HASH which contains
> the data from the operation. DON'T DO THAT!  I will not guarantee
> that these storage structures will stay the same. You break the OO
> encapsulation. Please suggest additional methods for my ::Operation
> object to collect the facts you need.

So ultimately what I want to do here is build an HTML form which
corresponds to the request expected by the SOAP method, so that in
some "development mode" you can submit SOAP requests and see the
responses. This is what you get from a .net-hosted SOAP service. Of
course there's a limit on the complexity of request which can be
represented in a form, so only fairly simple services can take
advantage of this, but it's still of value to developers.

I may have missed it but I didn't see a way to build the necessary
data structure from an ::Operation object, which is why there's that
hacky code in there for now, just outputting example documents (which
is of some value to us the way we're using this module now). Of
course, this stuff would not be in any released version!

>> I have a question - the name. Would XML::Compile::SOAP::PSGI be
>> appropriate, or should it live elsewhere?

[..]

> All these differences could be solved if you simply donate your
> implementation and let me maintain it (only applying bugfixes)
> It is simple to do that rewrite.  I did the same for the CGI code.
>
> However, you use the convensions of Plack (i presume). The code
> is a Plack::Component. It seems more logical to take a name in
> that namespace.

Actually I'm not taking anything more than a base constructor and
accessor implementation from Plack::Component, so that could be
trivially removed in favour of just doing it by hand in the module
itself.

I'd be more than happy to bring this module up to standard for you to
maintain, and have it be part of a suitable distribution.

> I will send you my 3.00 module under development off-list. It is in
> "raw", which means that the OODoc extension of POD is still merged
> with the code. Not released, because it needs to be tested. Some docs,
> tests and examples may still need to be adapted. If you have time,
> you can help me with that (at least do some reallife tests)

I will take a look and see how this works with our services, and how I
can simplify the PSGI implementation.

Thanks for the feedback.

Chris.