RE: [soaplite] SOAP::Lite autobinding problem
- I understand what Autobinding does, what I don't quite understand is why
it's causing the problems it does,
Effectively it's trying to make soap work as if it's pass-by-reference
instead of pass-by-value, so you can modify
the @_ array in the server and have the client's data be modified to reflect
In essence, The 'Object' (At least from a perl point of view) that is being
passed back and forth, is simply an additional element in the @_ array,
So the only question is, when taking the steps:
SOAP-Client serializes paramaters, creates "mapping" that can be mapped back
to the original parameters when returned from the server;
SOAP-Client Passes Serialized parameters to server;
SOAP-server deserializes paramaters, and calls requested function with said
SOAP-server re-serializes parameters (As they are with any changes) and
return value of function;
SOAP-server passes serialized parameters and return value(s) back to client;
SOAP-Client deserializes paramaters and return values, uses mapping to
update the objects referred to in step 1, places return values in
appropriate places to be retrieved by original caller.
How does SOAP lose track of which incoming parameter is which, from the
problem at hand, it sounds like SOAP doesn't use a very accurate map of
client references to returned server values, which I wouldn't think would be
very hard (I mean, if you stored them all in an array, and had that array
passed back, all the resulting values would be in the same places wouldn't
it??) The only thing I can think of is that there's an attemt to store them
in some sort of hash, mapping serialized references to actual references,
meaning there would be no way to tell for sure which object went with which
reference, if you had more than one of the same type.
Which overall doesn't sound like *that* hard of a problem to fix, if that's
the essence of the problem at hand...
Sorry, but that still just sounds like a bug that needs fixed *grin*
(Admittedly one that's probably not *incredibly* common to come across)
I'm still waiting for objects I pass from the client to the server to have
the method auto-bound to a return SOAP connection as well, so the server can
call methods in the client on objects passed from client-side to server-side
(I know, I know, don't hold my breath *cackle* :)
From: Duncan Cameron [mailto:dcameron@...]
Sent: Friday, August 30, 2002 3:23 AM
To: Leon Brocard
Subject: Re: [soaplite] SOAP::Lite autobinding problem
On 2002-08-29 Leon Brocard wrote:
>Duncan Cameron sent the following bits through the ether:
>> It's a problem with the autobinding, see the section of the docs
>> to see what SOAP::Lite is trying to do. Autobinding doesn't seem to
>> handle more than one parameter of the same type. You can work
>> around it by explicitly giving your parameter a different name, e.g.
>The section on autobinding in the docs doesn't point out that it is
Er, no. Most docs don't, but I agree that it doesn't explain any
>> $red->get(SOAP::Data->name(p1 => $green)); # passed extra object
>I don't see why I should have to work around a bug in SOAP::Lite. I
>would provide a patch to fix it if I could. Is the code around the
>comment "little bit tricky part that binds in/out parameters" the code
>I should be looking at?
Well, I think firstly we should specify what behaviour we expect. I'm
not sure that I understand quite what I do expect to happen!
Maybe having an option to turn-off auto-binding would be a start but
I think that the auto-binding code may well be supporting the transfer
of objects between client and server, so it might not be as simple
Bear in mind too that auto-binding and object transfer are not in
the SOAP definition, they are features that Paul has added. If you
want to inter-operate with other SOAP implementations then you
need to steer away from them.
Paul: can you clarify whether auto-binding could be turned-off and
what the consequences would be?
To unsubscribe from this group, send an email to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/