[Laszlo-user] Perl Catalyst

[Henry Minsky]

On 6/3/07, Geoff Crawford <geoff at innov8cs.com> wrote:
>
> At 10:35 AM 6/2/2007, John Sundman wrote:
>
> >Second, as of 4.0.2 the XML-RPC APIs now work in both DHTML and SWF
> >runtimes in SOLO mode -- no LPS required.
> >
>
> Thanks for that!
>
> Sounds like you might be the right person to ask a couple
> of questions on RPC - particularly SOAP.
>
> Any chance the SOAP will also be available to SOLO any
> time soon?



Hi, I'm doing the most current work on the RPC libraries in the SWF and
DHTML runtimes.
There are a bunch of good issues you've raised, I'll try to address some of
them
and give an overview of what the plans are. I cc'd this discussion to
Laszlo-Dev as well.



I'm currently working on some SOAP calls, which unfortunately
> the system is not following the WSDL and the name spacing
> is off.
>
> Ways I've thought of getting around it are:
>
> 1. just going to some plain XMLHttpRequest code - are you aware
> the DHTML version of XMLHttpRequest is broken?  I'm playing in
> SWF and working code complains about using lz.XMLHttpRequest
> because it's duplicating the name??  I can give you details
> and file a bug report if need be.


Please file a bug report, thanks!

The SWF implementation of XMLHTTPRequest  was just a simple wrapper around
the standard data loading API, to make AJAX programmers feel more at home.
That was put in long before we started implementing the DHTML runtime. Now
that we have DHTML, we need to figure out how to reconcile this. I'd like to
leave the native
DHTML XMLHTTPRequest, and rename the pseudo-XMLHTTPRequest class that is in
SWF, or at least make people use the 'lz' prefix, so there is no warning or
shadowing
going on.

2. I have to do 3 calls instead of one to get my XML dataset,
> otherwise I could fudge my own XML to the datatset's loading
> of the data. So I ruled that out.
>
> 3. I looked heavily at the dhtml (and SWF versions too) of
> rpc.js, namespace.js, and soap.js.  I thought I saw some
> serialize routines that were creating the XML in namespace.js,
> but changing that code didn't affect the XML generated in
> the SOAP request. I can sort of see where some of the values
> used in the SOAP envelope are being created, but not the actual
> XML body.  I'm thinking it builds some kind of prototypical
> XML at time of loading the WSDL.  If you could direct me to
> where that code is, I'd be happy to make some corrections.
>
> 4. Because my issue is with name spacing, I was thinking I
> might also be able to just change the name space lookup table
> to make it work.  Unfortunately I can't see to track down where
> it applies that table in order to know what changes in the
> table would produce the right name space.  Basically the
> WSDL calls for each request to have a name space value on
> the body that is equal to the domain default plus ":" and
> the port name.  The SOAP implementation ignores the WSDL's
> definition of the message it should build and uses a
> single value all the time that came from the WSDL:Definition
> section.  (I can confirm that because I mess with my
> WSDL and see that changing in the SOAP request)
>
> 5. Maybe if I someone could also point me to where the
> XML is being sent out, I could do a quick transformation
> on the one attribute of the one node in question.  How
> can I get access to what SOAP is sending out just before
> the actual XMLHttpRequest is invoked?
>
> OK so I'm going to push my luck here, and also ask if
> there isn't a way to share my WSDL between two different
> SOAP instances?  What I'd really love to see is the
> WSDL= be able to be set to a dataset instead of always
> being a URL.  I'm working on ERP systems - there are
> lots and lots of ports, and multiple operations in
> each of the ports.  Have you noticed the WSDL load
> is actually quite a bit slower than loading the same
> document into a dataset?  (not to mention the issues
> of async calls when you have 19 calls to the exact
> same WSDL document)  I have ideas about what that
> code should look like, but don't know enough of
> where to start.
>
> Thanks for listening anyway. ;-)


I'll post a separate message to laszlo-dev which outlines how the current
system works.
Briefly, it does do some XML serialization on the client to format the SOAP
request.
Then the message is passed to the server, which relies on the apache axis
library on the server to implement the SOAP transaction with the back-end,
and then that response is encoded as SWF byte code (for Flash) or  JSON (for
DHTML) and sent back to the client.
Some namespace issues may better be dealt with on the server end than on the
client.

What I'd really like to see is an implementation of the SOAP protocol
entirely in Javascript, that could be ported to LZX. That would  get the LPS
server and Apache-axis out of the loop entirely. This would allow SOLO  apps
to be SOAP clients. (And I'd like to do that with XMLRPC as well, which
should be an order of magnitude easier than the SOAP client implementation).

I've been looking around to see if anyone has implemented an
open source SOAP client in Javascript, but so far haven't found anything
that is even close to compliant with the spec. I'd be interested if you know
of anything that looks promising
in that area?

The LPS server  is currently using a fairly old version of the apache axis
and related utility libraries. There are some SOAP bugs that may be fixed by
moving to a more recent apache axis and related utility libraries, but the
apache APIs have drifted a lot, so this is not trivial.







-- 
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-user/attachments/20070603/83058f40/attachment-0001.html