[29542] in Perl-Users-Digest
Perl-Users Digest, Issue: 786 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Aug 23 14:10:00 2007
Date: Thu, 23 Aug 2007 11:09:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 23 Aug 2007 Volume: 11 Number: 786
Today's topics:
Re: Can I load a package's Autoload-able subs without e <ben@morrow.me.uk>
Re: Can I load a package's Autoload-able subs without e <bik.mido@tiscalinet.it>
Re: Perl sum of array and help with sorting <ben@morrow.me.uk>
Setting up a SOAP client that is technically a server <ravensdean@googlemail.com>
Re: Starting with SOAP <raherh@gmail.com>
Re: Starting with SOAP <perl4hire@softouch.on.ca>
Re: Starting with SOAP <perl4hire@softouch.on.ca>
Re: Starting with SOAP <scobloke2@infotop.co.uk>
Re: Starting with SOAP <scobloke2@infotop.co.uk>
Re: Starting with SOAP xhoster@gmail.com
Re: Starting with SOAP xhoster@gmail.com
Re: Starting with SOAP <perl4hire@softouch.on.ca>
Re: Starting with SOAP <perl4hire@softouch.on.ca>
Re: Starting with SOAP <perl4hire@softouch.on.ca>
Re: Starting with SOAP <perl4hire@softouch.on.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 23 Aug 2007 15:13:04 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Can I load a package's Autoload-able subs without executing them?
Message-Id: <g8h0q4-v24.ln1@osiris.mauzo.dyndns.org>
Quoth anno4000@radom.zrz.tu-berlin.de:
> <w.c.humann@arcor.de> wrote in comp.lang.perl.misc:
> > I want to be able to really load all subs in a given package,
> > including all load-on-demand subs.
<snip>
> > Why do I want to do this? I'm deriving from Devel::TraceCalls to see
> > what's going on inside my Perl/Tk application. For a while I wondered
> > why some functions never got traced. Well, when the tracer is
> > instantiated they are not there -- they are autoloaded later -- so the
> > tracer can't wrap them...
>
> Programmers frequently would like to do that. Yours is as good a reason
> as any.
>
> The sad truth is that it can't be done. All the mechanisms you mention
> are based on the behavior of the AUTOLOAD routine, which is called
> before the interpreter gives up on a sub name. This is described
> in perlsub. One fact is that AUTOLOAD doesn't even have to define
> the function it is called to "autoload". It could perform the
> function directly, depending on the sub name, and never leave a trace.
One solution would be to have your tracer install a trace on AUTOLOAD as
well, and handle it specially (noting the value of $AUTOLOAD, for
instance; and probably trying to install a trace on the autoloaded sub,
if it exists, after AUTOLOAD returns). Note that your problem here isn't
strictly autoloading: it's the fact that Perl allows you to modify the
symbol table at runtime. And there's no way around that: if a program
randomly inserts a new sub into the symbol table, there's no way for you
to find out.
Ben
--
The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching.
Assyrian stone tablet, c.2800 BC ben@morrow.me.uk
--
The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching.
Assyrian stone tablet, c.2800 BC ben@morrow.me.uk
------------------------------
Date: Thu, 23 Aug 2007 18:33:20 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Can I load a package's Autoload-able subs without executing them?
Message-Id: <mjdrc3p2h8gas8gd66hgfme7a3703tpr8o@4ax.com>
On Thu, 23 Aug 2007 15:13:04 +0100, Ben Morrow <ben@morrow.me.uk>
wrote:
>strictly autoloading: it's the fact that Perl allows you to modify the
>symbol table at runtime. And there's no way around that: if a program
>randomly inserts a new sub into the symbol table, there's no way for you
>to find out.
It would be nice if there were a hook to trigger say a sub, each time
something like this happens. It would probably be passed a copy of the
symtable as a hashref before the modification takes place and a copy
of it *after* it has.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Thu, 23 Aug 2007 14:49:05 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Perl sum of array and help with sorting
Message-Id: <hrf0q4-v24.ln1@osiris.mauzo.dyndns.org>
Quoth Michele Dondi <bik.mido@tiscalinet.it>:
> On Mon, 20 Aug 2007 19:44:12 -0000, elroyerni <davechunny@gmail.com>
> wrote:
>
> >sub sum_array {
> > my($sum) = 0; # initialize the sum to 0
> > foreach $i (@array_data) {
> > $sum = $sum + $i;
> > }
> > return($sum);
> >}
<snip>
> At this point the name is misleading at best, and I would probably go
> for just 'sum'. BTW: a completely equivalent but more perlish way in
> which probably most Perl programmers would write it is
>
> sub sum {
> my $sum;
> $sum += $_ for @_;
> $sum;
> }
Or
use List::Util qw/sum/;
:)
Ben
--
It will be seen that the Erwhonians are a meek and long-suffering people,
easily led by the nose, and quick to offer up common sense at the shrine of
logic, when a philosopher convinces them that their institutions are not based
on the strictest morality. [Samuel Butler, paraphrased] ben@morrow.me.uk
--
"Faith has you at a disadvantage, Buffy."
"'Cause I'm not crazy, or 'cause I don't kill people?"
"Both, actually."
[ben@morrow.me.uk]
------------------------------
Date: Thu, 23 Aug 2007 03:04:02 -0700
From: OwlHoot <ravensdean@googlemail.com>
Subject: Setting up a SOAP client that is technically a server
Message-Id: <1187863442.562253.242270@q3g2000prf.googlegroups.com>
I have a requirement for a process to distribute or "push" work, via
SOAP,
to a set of satellite processes.
When it starts each satellite must register its presence via SOAP with
the central process, and the latter must then connect as a client to
the
satellite with the latter technically acting as a SOAP server (to be
able
to wait for requests). Of course this means the central process must
use a distinct URL (with a unique/ephemeral port number?) for each
satellite process.
(This "back-to-front" approach is required because SOAP apparently
does not support client requests that will wait until data is
available
before returning from the SOAP call, and this polling will become
processor and network intensive when there are large numbers
of satellite processes.)
All the processes are written in perl, and although I've used
SOAP::Lite
in standard apps, both client and server, my experience doesn't extend
to the scenario described above and web searches for relevant code
examples have been fruitless.
If anyone can suggest a reference, preferably on the web, or sketch
client and server code that should achieve what I am after, that will
be much appreciated. One challenge is to decide on the URLs.
(Note that the satellite processes do not have to return results
via their "push" SOAP connections - For that purpose they can
act as conventional SOAP clients with the central process as
the SOAP server.)
Cheers
John R Ramsden
------------------------------
Date: Thu, 23 Aug 2007 09:20:36 +0200
From: rahed <raherh@gmail.com>
Subject: Re: Starting with SOAP
Message-Id: <ufy2abttn.fsf@gmail.com>
Amer Neely <perl4hire@softouch.on.ca> writes:
> When I do a search for 'soap::transport::http' at CPAN I get a list,
> and the first hit, SOAP::Transport::HTTP, takes me to
> SOAP-Lite-0.69'. The documentation leads me to believe that
> SOAP::Transport::HTTP is included in SOAP-Lite-0.69.
>
> Obviously I'm way off track in my belief system. This is one of the
> more confusing things I find about Perl.
With SOAP::Lite you can have both soap client and server and for light
loading there's a http daemon included (SOAP::Transport::HTTP).
--
Radek
------------------------------
Date: Thu, 23 Aug 2007 10:36:18 -0400
From: Amer Neely <perl4hire@softouch.on.ca>
Subject: Re: Starting with SOAP
Message-Id: <3Wgzi.510$tx1.322@read1.cgocable.net>
rahed wrote:
> Amer Neely <perl4hire@softouch.on.ca> writes:
>
>> When I do a search for 'soap::transport::http' at CPAN I get a list,
>> and the first hit, SOAP::Transport::HTTP, takes me to
>> SOAP-Lite-0.69'. The documentation leads me to believe that
>> SOAP::Transport::HTTP is included in SOAP-Lite-0.69.
>>
>> Obviously I'm way off track in my belief system. This is one of the
>> more confusing things I find about Perl.
>
> With SOAP::Lite you can have both soap client and server and for light
> loading there's a http daemon included (SOAP::Transport::HTTP).
>
Yes, that was my understanding. That is why I'm confused as to why I'm
getting an error message telling me it can't find can't locate
SOAP/Transport/HTTP.pm. As far as I can tell SOAP::Lite installed OK.
Bear in mind I'm absolutely new to SOAP and using code supplied as an
example in the documentation as a starting point. SOAP was suggested as
a means of getting some form data from one server to another, but I'm
beginning to wonder if it's worth it. If someone has an alternative
(besides the database route already suggested) please jump in.
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"
------------------------------
Date: Thu, 23 Aug 2007 10:45:44 -0400
From: Amer Neely <perl4hire@softouch.on.ca>
Subject: Re: Starting with SOAP
Message-Id: <V2hzi.511$tx1.263@read1.cgocable.net>
xhoster@gmail.com wrote:
> Amer Neely <perl4hire@softouch.on.ca> wrote:
>> xhoster@gmail.com wrote:
>>> Amer Neely <perl4hire@softouch.on.ca> wrote:
>>>> I need to update a script on one server with data from a form on
>>>> another server. It has been suggested that SOAP would work for this.
>>>> I've never used SOAP, and am overwhelmed with the number of 'SOAP*'
>>>> modules on CPAN. I've read that perhaps I should use a language with
>>>> better support for SOAP (PHP ?) but the existing script is in Perl and
>>>> I'd prefer to stick with that if possible.
>>> It sounds like the tail is wagging the dog. For one thing, you
>>> probably shouldn't update scripts based on form submissions. Why not
>>> update some database that the script accesses? That would probably
>>> solve the problem right there. But if you want Perl script-to-Perl
>>> script communication, pick a protocol that Perl is good at, rather than
>>> picking a random protocol and then figure out to implement in Perl.
>>>
>>> Xho
>>>
>> Sounds like good advice. However the 'other script' is not in my
>> control, and I'm not even sure it is Perl - likely PHP. The owner is the
>> one looking for a SOAP solution. They are asking for an XML document of
>> the form data.
>
> I'm still not sure I follow. You own one part and not the other part, and
> you want your part to be in Perl. But would your part be the SOAP client
> or the SOAP server? And what is this "form" data, is it a CGI form? And
> is that coming from the other party, or is their a third party submitting
> the form, which you are supposed to do convert into SOAP and pass it along?
You have it pretty much right. I built a form for a client, who now
wants to take that data and pass it to another server so it can be used
to update a page there. I don't own the receiving code (the SOAP
server?) but the owner suggested SOAP as a means to do this. Hence my
immersion into SOAP. A quick scan on CPAN revealed some 300 SOAP
modules, so I'm really sinking here.
>
>> At present the form data is not being saved in a database, so that is
>> not an immediate solution, although I could present that to my client
>> and the 3rd party.
>
> If the form isn't in soapy XML, and that is what they want it in, then
> just saving the form as is in a database isn't going to help. But anyway,
> I think there was miscommunication. You don't want to update a script
> (i.e. change the source code of a script) on another server, you just
> want to interact with a script on another server, right?
Yes, I just need to pass the form data (marked up as XML).
If so, then
> you might want to ask "What changes would your script make to the database
> if my script called your script the way you want it to? Why not just
> let me make those changes myself?" Unfortunately, many people think
> that the "right" way to do things is to treat the database just as some
> opaque bit-bucket and the "real" data lives in some XML-object model and
> therefore can't be assessed directly in the database. These people are
> almost always wrong, but sometimes they are the ones signing the
> paycheck.
I think you are under the impression there is a database already - there
isn't. I don't see why a database should be needed if SOAP works the way
it's presented (and if I understand it correctly).
>
> <snip errors>
>
> I think the module finding problems have already been addressed, but
> just a word of caution. Just because you can make a client and a
> server, both from Perl using SOAP::Lite, that will work with each other
> doesn't mean much. It doesn't mean the client will work with another
> language's server, or the server will work with another language's client.
>
> Xho
Well, I'm still stuck at this module finding stage, so it may have been
addressed but certainly not resolved. As you mention, both a client and
server can be built from SOAP::Lite. I'm trying to get something working
(a client and server) before I tackle passing the form data to a
third-party script.
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"
------------------------------
Date: Thu, 23 Aug 2007 16:48:59 +0100
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: Starting with SOAP
Message-Id: <46cdac70$0$13935$fa0fcedb@news.zen.co.uk>
Amer Neely wrote:
> rahed wrote:
>
>> Amer Neely <perl4hire@softouch.on.ca> writes:
>>
>>> When I do a search for 'soap::transport::http' at CPAN I get a list,
>>> and the first hit, SOAP::Transport::HTTP, takes me to
>>> SOAP-Lite-0.69'. The documentation leads me to believe that
>>> SOAP::Transport::HTTP is included in SOAP-Lite-0.69.
True AFAIK.
> I'm confused as to why I'm
> getting an error message telling me it can't find can't locate
> SOAP/Transport/HTTP.pm. As far as I can tell SOAP::Lite installed OK.
I think your problem is with installation of SOAP modules and not with
usage of SOAP or SOAP::Lite.
These commands should all return without any error messages
$ perl -MSOAP::Lite -e1
$ perl -MSOAP::Transport::HTTP -e1
$ perl -MSOAP::Transport::HTTP::CGI -e
Somewhere in one of the directories listed in @INC you should have
SOAP/Lite.pm
SOAP/Transport/HTTP.pm
SOAP/Transport/HTTP/CGI.pm
(and many other related modules)
> Bear in mind I'm absolutely new to SOAP and using code supplied as an
> example in the documentation as a starting point. SOAP was suggested as
> a means of getting some form data from one server to another, but I'm
> beginning to wonder if it's worth it. If someone has an alternative
> (besides the database route already suggested) please jump in.
>
For what it's worth, I find Perl and SOAP::Lite to be one of the easiest
SOAP implementations to use. I started with the simplest examples in the
documentation (e.g. The "Temperatures" examples in the Cookbook.
For more complicated services, SOAP::Lite can get a bit tricky, it
certainly has some limitations. I've managed to produce SOAP::Lite
web-services for consumption by .NET clients (C# Visual Studio) and
SOAP::Lite clients for complex Java web-services.
------------------------------
Date: Thu, 23 Aug 2007 17:01:35 +0100
From: Ian Wilson <scobloke2@infotop.co.uk>
Subject: Re: Starting with SOAP
Message-Id: <46cdaf64$0$13935$fa0fcedb@news.zen.co.uk>
Amer Neely wrote:
>>>>
>>> Sounds like good advice. However the 'other script' is not in my
>>> control, and I'm not even sure it is Perl - likely PHP. The owner is the
>>> one looking for a SOAP solution. They are asking for an XML document of
>>> the form data.
They should be able to provide WSDL which you can use.
> A quick scan on CPAN revealed some 300 SOAP
> modules, so I'm really sinking here.
Just use SOAP::Lite.
>> I think the module finding problems have already been addressed, but
>> just a word of caution. Just because you can make a client and a
>> server, both from Perl using SOAP::Lite, that will work with each other
>> doesn't mean much. It doesn't mean the client will work with another
>> language's server, or the server will work with another language's
>> client.
>
> Well, I'm still stuck at this module finding stage,
What platform (OS and version)?
What version of perl
How did you obtain and install SOAP::Lite ?
`perl -MCPAN ...` ?
`ppm install ...` ?
> so it may have been
> addressed but certainly not resolved. As you mention, both a client and
> server can be built from SOAP::Lite. I'm trying to get something working
> (a client and server) before I tackle passing the form data to a
> third-party script.
>
Good plan.
------------------------------
Date: 23 Aug 2007 16:47:01 GMT
From: xhoster@gmail.com
Subject: Re: Starting with SOAP
Message-Id: <20070823124702.747$sP@newsreader.com>
Amer Neely <perl4hire@softouch.on.ca> wrote:
> xhoster@gmail.com wrote:
> > I'm still not sure I follow. You own one part and not the other part,
> > and you want your part to be in Perl. But would your part be the SOAP
> > client or the SOAP server? And what is this "form" data, is it a CGI
> > form? And is that coming from the other party, or is their a third
> > party submitting the form, which you are supposed to do convert into
> > SOAP and pass it along?
>
> You have it pretty much right. I built a form for a client, who now
> wants to take that data and pass it to another server so it can be used
> to update a page there. I don't own the receiving code (the SOAP
> server?) but the owner suggested SOAP as a means to do this. Hence my
> immersion into SOAP. A quick scan on CPAN revealed some 300 SOAP
> modules, so I'm really sinking here.
>
> >
> >> At present the form data is not being saved in a database, so that is
> >> not an immediate solution, although I could present that to my client
> >> and the 3rd party.
> >
> > If the form isn't in soapy XML, and that is what they want it in, then
> > just saving the form as is in a database isn't going to help. But
> > anyway, I think there was miscommunication. You don't want to update a
> > script (i.e. change the source code of a script) on another server, you
> > just want to interact with a script on another server, right?
>
> Yes, I just need to pass the form data (marked up as XML).
>
> If so, then
> > you might want to ask "What changes would your script make to the
> > database if my script called your script the way you want it to? Why
> > not just let me make those changes myself?" Unfortunately, many people
> > think that the "right" way to do things is to treat the database just
> > as some opaque bit-bucket and the "real" data lives in some XML-object
> > model and therefore can't be assessed directly in the database. These
> > people are almost always wrong, but sometimes they are the ones signing
> > the paycheck.
>
> I think you are under the impression there is a database already - there
> isn't.
Sure there is. Whatever the other end is doing that makes a permanent
change, that is a database. It may not be a RDBMS, but surely it is
something, a informal database implemented with the file system, perhaps.
> I don't see why a database should be needed if SOAP works the way
> it's presented (and if I understand it correctly).
I just think you are adding an needless complication. Instead of
submitting a form to a Perl script, which then translates it into a
different language and submits that to another server, why not just submit
the form directly to the end server?
> >
> > I think the module finding problems have already been addressed, but
> > just a word of caution. Just because you can make a client and a
> > server, both from Perl using SOAP::Lite, that will work with each other
> > doesn't mean much. It doesn't mean the client will work with another
> > language's server, or the server will work with another language's
> > client.
> >
> > Xho
>
> Well, I'm still stuck at this module finding stage, so it may have been
> addressed but certainly not resolved. As you mention, both a client and
> server can be built from SOAP::Lite. I'm trying to get something working
> (a client and server) before I tackle passing the form data to a
> third-party script.
SOAP::Transport::HTTP.pm seems to be part of SOAP::Lite package, while
SOAP::Transport::HTTP::CGI.pm is part of the SOAP package. So if you are
install from CPAN, you would need to install both SOAP and SOAP::Lite.
It all seems needlessly complicated to me, but then again so does
*everything* touching on SOAP.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 23 Aug 2007 16:56:18 GMT
From: xhoster@gmail.com
Subject: Re: Starting with SOAP
Message-Id: <20070823125619.729$PH@newsreader.com>
Ian Wilson <scobloke2@infotop.co.uk> wrote:
> Amer Neely wrote:
> >>>>
> >>> Sounds like good advice. However the 'other script' is not in my
> >>> control, and I'm not even sure it is Perl - likely PHP. The owner is
> >>> the one looking for a SOAP solution. They are asking for an XML
> >>> document of the form data.
>
> They should be able to provide WSDL which you can use.
>
> > A quick scan on CPAN revealed some 300 SOAP
> > modules, so I'm really sinking here.
>
> Just use SOAP::Lite.
What did you have to do to get this to work? What version of SOAP::Lite do
you use? When I point SOAP::Lite at a .net WSDL, it just dies from
internal errors.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Thu, 23 Aug 2007 13:43:53 -0400
From: Amer Neely <perl4hire@softouch.on.ca>
Subject: Re: Starting with SOAP
Message-Id: <WFjzi.620$tx1.604@read1.cgocable.net>
Ian Wilson wrote:
> Amer Neely wrote:
>> rahed wrote:
>>
>>> Amer Neely <perl4hire@softouch.on.ca> writes:
>>>
>>>> When I do a search for 'soap::transport::http' at CPAN I get a list,
>>>> and the first hit, SOAP::Transport::HTTP, takes me to
>>>> SOAP-Lite-0.69'. The documentation leads me to believe that
>>>> SOAP::Transport::HTTP is included in SOAP-Lite-0.69.
>
> True AFAIK.
>
>
>> I'm confused as to why I'm getting an error message telling me it
>> can't find can't locate SOAP/Transport/HTTP.pm. As far as I can tell
>> SOAP::Lite installed OK.
>
> I think your problem is with installation of SOAP modules and not with
> usage of SOAP or SOAP::Lite.
That could be. I'll try installing again, and capture the output.
> These commands should all return without any error messages
> $ perl -MSOAP::Lite -e1
> $ perl -MSOAP::Transport::HTTP -e1
> $ perl -MSOAP::Transport::HTTP::CGI -e
No code specified for -e.
... so I figured you forgot the '1' ...
Can't locate SOAP/Transport/HTTP/CGI.pm in @INC (@INC contains:
C:/usr/site/lib
C:/usr/lib .).
BEGIN failed--compilation aborted.
This is on my home PC, which is acting as the 'client'.
Directory of C:\usr\lib\SOAP
15/08/2007 09:16p <DIR> .
15/08/2007 09:16p <DIR> ..
08/12/2003 09:13a 167,831 Lite.pm
17/04/2002 01:16a 12,182 Test.pm
15/08/2007 09:15p <DIR> Transport
Directory of C:\usr\lib\SOAP\Transport
15/08/2007 09:15p <DIR> .
15/08/2007 09:15p <DIR> ..
14/06/2002 10:13a 3,147 FTP.pm
14/06/2002 10:13a 29,726 HTTP.pm
14/06/2002 10:13a 3,282 IO.pm
14/06/2002 10:13a 8,156 JABBER.pm
17/04/2002 01:16a 2,052 LOCAL.pm
14/06/2002 10:13a 3,749 MAILTO.pm
14/06/2002 10:13a 7,813 MQ.pm
14/06/2002 10:13a 3,744 POP3.pm
14/06/2002 10:13a 6,940 TCP.pm
There is no 'SOAP' directory under /usr/site/lib
>
> Somewhere in one of the directories listed in @INC you should have
> SOAP/Lite.pm
> SOAP/Transport/HTTP.pm
> SOAP/Transport/HTTP/CGI.pm
> (and many other related modules)
So it appears my installation is flawed. I will re-install.
>
>> Bear in mind I'm absolutely new to SOAP and using code supplied as an
>> example in the documentation as a starting point. SOAP was suggested
>> as a means of getting some form data from one server to another, but
>> I'm beginning to wonder if it's worth it. If someone has an
>> alternative (besides the database route already suggested) please jump
>> in.
>>
>
> For what it's worth, I find Perl and SOAP::Lite to be one of the easiest
> SOAP implementations to use. I started with the simplest examples in the
> documentation (e.g. The "Temperatures" examples in the Cookbook.
Yes, I got that one to work fine too. Which gave me encouragement.
> For more complicated services, SOAP::Lite can get a bit tricky, it
> certainly has some limitations. I've managed to produce SOAP::Lite
> web-services for consumption by .NET clients (C# Visual Studio) and
> SOAP::Lite clients for complex Java web-services.
I think you are right in that my installation may be flawed - I will
re-install SOAP.
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"
------------------------------
Date: Thu, 23 Aug 2007 13:50:03 -0400
From: Amer Neely <perl4hire@softouch.on.ca>
Subject: Re: Starting with SOAP
Message-Id: <ILjzi.621$tx1.239@read1.cgocable.net>
Ian Wilson wrote:
> Amer Neely wrote:
>>>>>
>>>> Sounds like good advice. However the 'other script' is not in my
>>>> control, and I'm not even sure it is Perl - likely PHP. The owner is
>>>> the
>>>> one looking for a SOAP solution. They are asking for an XML document of
>>>> the form data.
>
> They should be able to provide WSDL which you can use.
>
>> A quick scan on CPAN revealed some 300 SOAP modules, so I'm really
>> sinking here.
>
> Just use SOAP::Lite.
I'm trying, (very trying :)
>>> I think the module finding problems have already been addressed, but
>>> just a word of caution. Just because you can make a client and a
>>> server, both from Perl using SOAP::Lite, that will work with each other
>>> doesn't mean much. It doesn't mean the client will work with another
>>> language's server, or the server will work with another language's
>>> client.
>
>
>>
>> Well, I'm still stuck at this module finding stage,
>
> What platform (OS and version)?
Win2K Professional
> What version of perl
ActiveState
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 50 registered patches, see perl -V for more detail)
> How did you obtain and install SOAP::Lite ?
> `ppm install ...` ?
via the GUI. Version 4.01
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"
------------------------------
Date: Thu, 23 Aug 2007 13:53:26 -0400
From: Amer Neely <perl4hire@softouch.on.ca>
Subject: Re: Starting with SOAP
Message-Id: <TOjzi.522$k22.429@read2.cgocable.net>
xhoster@gmail.com wrote:
> Ian Wilson <scobloke2@infotop.co.uk> wrote:
>> Amer Neely wrote:
>>>>> Sounds like good advice. However the 'other script' is not in my
>>>>> control, and I'm not even sure it is Perl - likely PHP. The owner is
>>>>> the one looking for a SOAP solution. They are asking for an XML
>>>>> document of the form data.
>> They should be able to provide WSDL which you can use.
>>
>>> A quick scan on CPAN revealed some 300 SOAP
>>> modules, so I'm really sinking here.
>> Just use SOAP::Lite.
>
> What did you have to do to get this to work? What version of SOAP::Lite do
> you use? When I point SOAP::Lite at a .net WSDL, it just dies from
> internal errors.
>
> Xho
>
As mentioned in my reply to Ian Wilson, I'm using ActiveState on Win2K
Professional
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 50 registered patches, see perl -V for more detail)
so installed SOAP::Lite with the GUI ppm 4.01. But it seems some of the
modules didn't get installed, so I'm going to try a re-install from AS.
Failing that I will try the 'make ....' routine from CPAN.
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"
------------------------------
Date: Thu, 23 Aug 2007 14:02:26 -0400
From: Amer Neely <perl4hire@softouch.on.ca>
Subject: Re: Starting with SOAP
Message-Id: <kXjzi.622$tx1.95@read1.cgocable.net>
xhoster@gmail.com wrote:
> Amer Neely <perl4hire@softouch.on.ca> wrote:
>> xhoster@gmail.com wrote:
>
>>> I'm still not sure I follow. You own one part and not the other part,
>>> and you want your part to be in Perl. But would your part be the SOAP
>>> client or the SOAP server? And what is this "form" data, is it a CGI
>>> form? And is that coming from the other party, or is their a third
>>> party submitting the form, which you are supposed to do convert into
>>> SOAP and pass it along?
>> You have it pretty much right. I built a form for a client, who now
>> wants to take that data and pass it to another server so it can be used
>> to update a page there. I don't own the receiving code (the SOAP
>> server?) but the owner suggested SOAP as a means to do this. Hence my
>> immersion into SOAP. A quick scan on CPAN revealed some 300 SOAP
>> modules, so I'm really sinking here.
>>
>>>> At present the form data is not being saved in a database, so that is
>>>> not an immediate solution, although I could present that to my client
>>>> and the 3rd party.
>>> If the form isn't in soapy XML, and that is what they want it in, then
>>> just saving the form as is in a database isn't going to help. But
>>> anyway, I think there was miscommunication. You don't want to update a
>>> script (i.e. change the source code of a script) on another server, you
>>> just want to interact with a script on another server, right?
>> Yes, I just need to pass the form data (marked up as XML).
>>
>> If so, then
>>> you might want to ask "What changes would your script make to the
>>> database if my script called your script the way you want it to? Why
>>> not just let me make those changes myself?" Unfortunately, many people
>>> think that the "right" way to do things is to treat the database just
>>> as some opaque bit-bucket and the "real" data lives in some XML-object
>>> model and therefore can't be assessed directly in the database. These
>>> people are almost always wrong, but sometimes they are the ones signing
>>> the paycheck.
>> I think you are under the impression there is a database already - there
>> isn't.
>
> Sure there is. Whatever the other end is doing that makes a permanent
> change, that is a database. It may not be a RDBMS, but surely it is
> something, a informal database implemented with the file system, perhaps.
Ah, OK, I'll accept that.
>> I don't see why a database should be needed if SOAP works the way
>> it's presented (and if I understand it correctly).
>
> I just think you are adding an needless complication. Instead of
> submitting a form to a Perl script, which then translates it into a
> different language and submits that to another server, why not just submit
> the form directly to the end server?
I'm just going on what was suggested by the owner of the 'other' script.
The form data is to be used on 2 separate servers - in other words
duplicated 'live' on the other server. He seems to think sending the
form data as an XML message is the simplest way to do this.
>>> I think the module finding problems have already been addressed, but
>>> just a word of caution. Just because you can make a client and a
>>> server, both from Perl using SOAP::Lite, that will work with each other
>>> doesn't mean much. It doesn't mean the client will work with another
>>> language's server, or the server will work with another language's
>>> client.
>>>
>>> Xho
>> Well, I'm still stuck at this module finding stage, so it may have been
>> addressed but certainly not resolved. As you mention, both a client and
>> server can be built from SOAP::Lite. I'm trying to get something working
>> (a client and server) before I tackle passing the form data to a
>> third-party script.
>
> SOAP::Transport::HTTP.pm seems to be part of SOAP::Lite package, while
> SOAP::Transport::HTTP::CGI.pm is part of the SOAP package. So if you are
> install from CPAN, you would need to install both SOAP and SOAP::Lite.
>
Yes, I'm beginning to see some light in there as well. The documentation
I find seems to assume a great deal of knowledge on my part already.
> It all seems needlessly complicated to me, but then again so does
> *everything* touching on SOAP.
I'm glad I'm not the only one :)
--
Amer Neely
w: www.webmechanic.softouch.on.ca/
Perl | MySQL programming for all data entry forms.
"Others make web sites. We make web sites work!"
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 786
**************************************
