Hi, David!

> Thanks for the help...  I'm having trouble with the statement:
>
> die "No such method...\n" unless exists $%methods_map{$method};
should be:

die "No such method...\n" unless exists $methods_map{$method};

I didn't test it, just typed out of my head.

> Since I'm new to perl, I'm not sure what the problem is.  It works
I advise you to stay with more simple case (access from your client
only classes/methods you really have on server) and then move toward
more complex case you discussed.

Best wishes, Paul.

--- David Mullens <damullens@...> wrote:
> Hi,
>
> Thanks for the help...  I'm having trouble with the statement:
>
> die "No such method...\n" unless exists $%methods_map{$method};
>
> It seems to be $%methods_map{$method} that is causing the trouble.
> I get
> the error: Bareword found where operator expected at
> ./MainInterface.cgi
> line 21, near "$%methods_map"
>         (Missing operator before methods_map?)
>
> Since I'm new to perl, I'm not sure what the problem is.  It works
> fine if I
> put it in the die "No.....$%methods_map{$method}"..... statement.
>
> Thanks for the help.
>
> DAve.
>
>
>
> -----Original Message-----
> From: soaplite@yahoogroups.com [mailto:soaplite@yahoogroups.com]
> Sent: Tuesday, July 31, 2001 8:44 PM
> To: soaplite@yahoogroups.com
> Subject: Re: [soaplite] General Question
> Importance: Low
>
>
> Hi, David!
>
> >> I'm wanting to have several small scripts (modules) called from
> a
> >> large main
> it IS definitely possible. Yet I'm not sure that is right approach.
> Combination of URI and method will tell you what module/method to
> use. You want to fix URI and map method to different combinations
> of
> module/method on server side. Doable, but I'd rather create one
> AUTOLOAD function and build it dynamically from hash:
>
> use SOAP::Transport::HTTP;
> SOAP::Transport::HTTP::CGI
>   -> dispatch_to('MainInterface')
>   -> handle;
>
> package MainInterface;
>
> use vars qw($AUTOLOAD);
>
> my %methods_map = (
>   method1 => ['package', 'method'],
>   method2 => ['package', 'method1'],
> );
>
> sub AUTOLOAD {
>   my $method = substr($AUTOLOAD, rindex($AUTOLOAD, '::') + 2);
>   return if $method eq 'DESTROY';
>
>   die "No such method...\n" unless exists $%methods_map{$method};
>   my($package, $method) = @{$methods_map{$method}};
>   eval "require $package" or die;
>   # little trick that allows you to implement
>   # method (OO) rather than function calls
>   $method = "${package}::$method";
>   shift->$method(@_);
>   # don't forget that first parameter is class/object
>   # shift it if you don't need that
> }
>
> All other modules can be implemented in usual fashion.
>
> >> In the Methods module, I would have
> >>
> >> use SOAP::Transport::HTTP;
> >> SOAP::Transport::HTTP::CGI
> >>    -> dispatch_to('Modules')
> >>    -> handle;
> you don't need that in Methods module, only usual module code.
>
> >> Is this possible?  Right now I'm getting an access denied.
> Access denien where? Could you provide request/response payload if
> you still have problems? Hope it helps.
>
> Best wishes, Paul.
>
> --- David Mullens <damullens@...> wrote:
> >> Hi,
> >>
> >> I'm wanting to have several small scripts (modules) called from
> a
> >> large main
> >> script.  The main script would basically have:
> >>
> >>
> >> use SOAP::Transport::HTTP;
> >> SOAP::Transport::HTTP::CGI
> >>    -> dispatch_to('MainInterface')
> >>    -> handle;
> >>
> >> package MainInterface;
> >>
> >> use Methods;
> >>
> >> sub methodName {
> >>   &Methods::method_Name;
> >> }
> >>
> >>
> >>
> >> In the Methods module, I would have
> >>
> >> use SOAP::Transport::HTTP;
> >> SOAP::Transport::HTTP::CGI
> >>    -> dispatch_to('Modules')
> >>    -> handle;
> >>
> >> sub method_Name {
> >>   # some type of logic here
> >>
> >>   return $whatever;
> >> }
> >>
> >>
> >> For each subroutine in the main script, there would be a module.
> >>
> >> The reason why we are wanting to implement SOAP this way, is  so
> we
> >> can
> >> setup the endpoint url in a database (or java properties file)
> and
> >> the
> >> person programming the client won't have to worry about
> different
> >> endpoints,
> >> only the method to call.  We can create new modules, then enter
> >> them in our
> >> main endpoint script.  The main script will take care of the
> call.
> >>
> >> When ever something needs to be updated, we don't have to touch
> the
> >> main
> >> endpoint script at all.  We can edit whatever module we want.
> >> There is a
> >> chance that we will have 200 or  so modules when all is
> finished.
> >>
> >> Is this possible?  Right now I'm getting an access denied.
> >>
> >> Is this the best way to implement things?  We really don't want
> one
> >> script
> >> with 200 subroutines (at least with all the logic) and we don't
> >> want one
> >> script for each endpoint.  We thought if we implement it with
> one
> >> main
> >> script calling different modules, it would be easier to
> maintain.
> >>
> >>
> >>
> >> Thanks for any suggestions,
> >>
> >> Dave.
> >>
> >>
> >> ------------------------ Yahoo! Groups Sponsor
> >>
> >> To unsubscribe from this group, send an email to:
> >> soaplite-unsubscribe@yahoogroups.com
> >>
> >>
> >>
> >> Your use of Yahoo! Groups is subject to
> >> http://docs.yahoo.com/info/terms/
> >>
> >>
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo!
> Messenger
> http://phonecard.yahoo.com/
>
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Thanks again for all your help!  I think I see how I can do it now!  You've
helped a lot.

Now on to authentication.......

Peace,

Dave.

-----Original Message-----
From: soaplite@yahoogroups.com [mailto:soaplite@yahoogroups.com]
Sent: Wednesday, August 01, 2001 12:32 PM
To: soaplite@yahoogroups.com
Subject: RE: [soaplite] General Question
Importance: Low


Hi, David!

>> Thanks for the help...  I'm having trouble with the statement:
>>
>> die "No such method...\n" unless exists $%methods_map{$method};
should be:

die "No such method...\n" unless exists $methods_map{$method};

I didn't test it, just typed out of my head.

>> Since I'm new to perl, I'm not sure what the problem is.  It works
I advise you to stay with more simple case (access from your client
only classes/methods you really have on server) and then move toward
more complex case you discussed.

Best wishes, Paul.

--- David Mullens <damullens@...> wrote:
>> Hi,
>>
>> Thanks for the help...  I'm having trouble with the statement:
>>
>> die "No such method...\n" unless exists $%methods_map{$method};
>>
>> It seems to be $%methods_map{$method} that is causing the trouble.
>> I get
>> the error: Bareword found where operator expected at
>> ./MainInterface.cgi
>> line 21, near "$%methods_map"
>>         (Missing operator before methods_map?)
>>
>> Since I'm new to perl, I'm not sure what the problem is.  It works
>> fine if I
>> put it in the die "No.....$%methods_map{$method}"..... statement.
>>
>> Thanks for the help.
>>
>> DAve.
>>
>>
>>
>> -----Original Message-----
>> From: soaplite@yahoogroups.com [mailto:soaplite@yahoogroups.com]
>> Sent: Tuesday, July 31, 2001 8:44 PM
>> To: soaplite@yahoogroups.com
>> Subject: Re: [soaplite] General Question
>> Importance: Low
>>
>>
>> Hi, David!
>>
>> >> I'm wanting to have several small scripts (modules) called from
>> a
>> >> large main
>> it IS definitely possible. Yet I'm not sure that is right approach.
>> Combination of URI and method will tell you what module/method to
>> use. You want to fix URI and map method to different combinations
>> of
>> module/method on server side. Doable, but I'd rather create one
>> AUTOLOAD function and build it dynamically from hash:
>>
>> use SOAP::Transport::HTTP;
>> SOAP::Transport::HTTP::CGI
>>   -> dispatch_to('MainInterface')
>>   -> handle;
>>
>> package MainInterface;
>>
>> use vars qw($AUTOLOAD);
>>
>> my %methods_map = (
>>   method1 => ['package', 'method'],
>>   method2 => ['package', 'method1'],
>> );
>>
>> sub AUTOLOAD {
>>   my $method = substr($AUTOLOAD, rindex($AUTOLOAD, '::') + 2);
>>   return if $method eq 'DESTROY';
>>
>>   die "No such method...\n" unless exists $%methods_map{$method};
>>   my($package, $method) = @{$methods_map{$method}};
>>   eval "require $package" or die;
>>   # little trick that allows you to implement
>>   # method (OO) rather than function calls
>>   $method = "${package}::$method";
>>   shift->$method(@_);
>>   # don't forget that first parameter is class/object
>>   # shift it if you don't need that
>> }
>>
>> All other modules can be implemented in usual fashion.
>>
>> >> In the Methods module, I would have
>> >>
>> >> use SOAP::Transport::HTTP;
>> >> SOAP::Transport::HTTP::CGI
>> >>    -> dispatch_to('Modules')
>> >>    -> handle;
>> you don't need that in Methods module, only usual module code.
>>
>> >> Is this possible?  Right now I'm getting an access denied.
>> Access denien where? Could you provide request/response payload if
>> you still have problems? Hope it helps.
>>
>> Best wishes, Paul.
>>
>> --- David Mullens <damullens@...> wrote:
>> >> Hi,
>> >>
>> >> I'm wanting to have several small scripts (modules) called from
>> a
>> >> large main
>> >> script.  The main script would basically have:
>> >>
>> >>
>> >> use SOAP::Transport::HTTP;
>> >> SOAP::Transport::HTTP::CGI
>> >>    -> dispatch_to('MainInterface')
>> >>    -> handle;
>> >>
>> >> package MainInterface;
>> >>
>> >> use Methods;
>> >>
>> >> sub methodName {
>> >>   &Methods::method_Name;
>> >> }
>> >>
>> >>
>> >>
>> >> In the Methods module, I would have
>> >>
>> >> use SOAP::Transport::HTTP;
>> >> SOAP::Transport::HTTP::CGI
>> >>    -> dispatch_to('Modules')
>> >>    -> handle;
>> >>
>> >> sub method_Name {
>> >>   # some type of logic here
>> >>
>> >>   return $whatever;
>> >> }
>> >>
>> >>
>> >> For each subroutine in the main script, there would be a module.
>> >>
>> >> The reason why we are wanting to implement SOAP this way, is  so
>> we
>> >> can
>> >> setup the endpoint url in a database (or java properties file)
>> and
>> >> the
>> >> person programming the client won't have to worry about
>> different
>> >> endpoints,
>> >> only the method to call.  We can create new modules, then enter
>> >> them in our
>> >> main endpoint script.  The main script will take care of the
>> call.
>> >>
>> >> When ever something needs to be updated, we don't have to touch
>> the
>> >> main
>> >> endpoint script at all.  We can edit whatever module we want.
>> >> There is a
>> >> chance that we will have 200 or  so modules when all is
>> finished.
>> >>
>> >> Is this possible?  Right now I'm getting an access denied.
>> >>
>> >> Is this the best way to implement things?  We really don't want
>> one
>> >> script
>> >> with 200 subroutines (at least with all the logic) and we don't
>> >> want one
>> >> script for each endpoint.  We thought if we implement it with
>> one
>> >> main
>> >> script calling different modules, it would be easier to
>> maintain.
>> >>
>> >>
>> >>
>> >> Thanks for any suggestions,
>> >>
>> >> Dave.
>> >>
>> >>
>> >> ------------------------ Yahoo! Groups Sponsor
>> >>
>> >> To unsubscribe from this group, send an email to:
>> >> soaplite-unsubscribe@yahoogroups.com
>> >>
>> >>
>> >>
>> >> Your use of Yahoo! Groups is subject to
>> >> http://docs.yahoo.com/info/terms/
>> >>
>> >>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Make international calls for as low as $.04/minute with Yahoo!
>> Messenger
>> http://phonecard.yahoo.com/
>>
>>
>> To unsubscribe from this group, send an email to:
>> soaplite-unsubscribe@yahoogroups.com
>>
>>
>>
>> Your use of Yahoo! Groups is subject to
>> http://docs.yahoo.com/info/terms/
>>
>>
>>
>>
>>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/


To unsubscribe from this group, send an email to:
soaplite-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

What tool(s) do you guys use to create a WSDL file?
I suppose if one uses Microsoft's .NET stuff, it will create the
corresponding WSDL for you. Other tools?

Thanks.

Weidong

Hello,


The examples were up and ruunning in less than an hour!!! Great
Stuff!!!

I am using soap.tcp (server) with chat.pl (client) on NT.

The following warning message is written out (by soap.tcp) for every
server request:

Use of uninitialized value in numeric eq (==) at
C:/perl/site/lib/IO/SessionData.pm line 160.

Version = ActivePerl 5.6.1.628

Thanks in advance for any assistance,

Jeff

Hi, Jeff!

> The following warning message is written out (by soap.tcp) for
> every server request:
You may safely ignore that, but it won't be shown anymore (starting
the next version). Thanks for the information.

Best wishes, Paul.

--- jeffforbeck@... wrote:
> Hello,
>
>
> The examples were up and ruunning in less than an hour!!! Great
> Stuff!!!
>
> I am using soap.tcp (server) with chat.pl (client) on NT.
>
> The following warning message is written out (by soap.tcp) for
> every
> server request:
>
> Use of uninitialized value in numeric eq (==) at
> C:/perl/site/lib/IO/SessionData.pm line 160.
>
> Version = ActivePerl 5.6.1.628
>
> Thanks in advance for any assistance,
>
> Jeff
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Hello Paul,

Thank you for the quick response. This may end my middleware
(COM/CORBA) headaches forever.....

Keep up the great work!

Thanks again,

Jeff

--- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
> Hi, Jeff!
>
> > The following warning message is written out (by soap.tcp) for
> > every server request:
> You may safely ignore that, but it won't be shown anymore (starting
> the next version). Thanks for the information.
>
> Best wishes, Paul.
>
> --- jeffforbeck@y... wrote:
> > Hello,
> >
> >
> > The examples were up and ruunning in less than an hour!!! Great
> > Stuff!!!
> >
> > I am using soap.tcp (server) with chat.pl (client) on NT.
> >
> > The following warning message is written out (by soap.tcp) for
> > every
> > server request:
> >
> > Use of uninitialized value in numeric eq (==) at
> > C:/perl/site/lib/IO/SessionData.pm line 160.
> >
> > Version = ActivePerl 5.6.1.628
> >
> > Thanks in advance for any assistance,
> >
> > Jeff
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> >
> > To unsubscribe from this group, send an email to:
> > soaplite-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo!
Messenger
> http://phonecard.yahoo.com/

I just used MS's Visual Studio.NET and built the HelloWorld web service
(with both C# and VB).

It runs with the MS tools (using GET/POST), but not a SOAP call.

So I wrote a small soap-lite script to make the call, making sure to modify
the SOAPAction field. Using debug, I can tell that the client sends the
request and the sever responds with the result. However, there are three
extra bytes in front of <?xml ....>, and soap-lite does not like it. The
debug output is attached below.

Has anyone seen this before? With a network monitor, I can see that those 3
characters's hex code are:

EF BB BF

Thanks.

Weidong



SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Fri, 03 Aug 2001 18:03:01 GMT
Server: Microsoft-IIS/5.0
Content-Length: 409
Content-Type: text/xml; charset=utf-8
Client-Date: Fri, 03 Aug 2001 18:03:01 GMT
Client-Peer: 127.0.0.1:8080

???<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Body>
     <HelloWorldResponse xmlns="http://tempuri.orgt/webservices/">
       <HelloWorldResult>Hello World</HelloWorldResult>
     </HelloWorldResponse>
   </soap:Body>
</soap:Envelope>
SOAP::Deserializer::deserialize: ()
SOAP::Parser::decode: ()

unclosed token at line 8, column 2695, byte 3088 at
C:/Perl/site/lib/XML/Parser.pm line 185

Hi, Weidong!

> Has anyone seen this before? With a network monitor, I can see that
> those 3 characters's hex code are:
>
> EF BB BF
It's BOM (byte order mark). Expat has bug in handling BOMs in
combination with UTF-8 encoding, so SOAP::Lite chokes on it. Here is
the code that fixes that, but you should use it only with BOMs on
utf-8 encoding.

# drop BOM, so XML::Parser won't choke on it
use SOAP::Lite +trace => [transport => sub {
   if (UNIVERSAL::isa($_[0] => 'HTTP::Response')) {
     my $c = $_[0]->content;
     $_[0]->content($c) if $c =~ s/^[^<]{2,3}</</;
   }
}];

Latest Expat (1.95.2, released couple of days ago) should not have
this problem.

Best wishes, Paul.

--- Weidong Wang <wwang@...> wrote:
> I just used MS's Visual Studio.NET and built the HelloWorld web
> service
> (with both C# and VB).
>
> It runs with the MS tools (using GET/POST), but not a SOAP call.
>
> So I wrote a small soap-lite script to make the call, making sure
> to modify
> the SOAPAction field. Using debug, I can tell that the client sends
> the
> request and the sever responds with the result. However, there are
> three
> extra bytes in front of <?xml ....>, and soap-lite does not like
> it. The
> debug output is attached below.
>
> Has anyone seen this before? With a network monitor, I can see that
> those 3
> characters's hex code are:
>
> EF BB BF
>
> Thanks.
>
> Weidong
>
>
>
> SOAP::Transport::HTTP::Client::send_receive: HTTP/1.1 200 OK
> Cache-Control: private, max-age=0
> Date: Fri, 03 Aug 2001 18:03:01 GMT
> Server: Microsoft-IIS/5.0
> Content-Length: 409
> Content-Type: text/xml; charset=utf-8
> Client-Date: Fri, 03 Aug 2001 18:03:01 GMT
> Client-Peer: 127.0.0.1:8080
>
> ???<?xml version="1.0" encoding="utf-8"?>
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>   <soap:Body>
>     <HelloWorldResponse xmlns="http://tempuri.orgt/webservices/">
>       <HelloWorldResult>Hello World</HelloWorldResult>
>     </HelloWorldResponse>
>   </soap:Body>
> </soap:Envelope>
> SOAP::Deserializer::deserialize: ()
> SOAP::Parser::decode: ()
>
> unclosed token at line 8, column 2695, byte 3088 at
> C:/Perl/site/lib/XML/Parser.pm line 185
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Hello,
I have a question about Persistent server-side objects without using the
autodispatch mode.

In the SOAP::Lite POD Docs, it says, under "implementation of OO interface"
that you can have a remote object on the server as well as make local calls
to it using the alternative "call" interface. I have pasted the example for
using the call() interface below:

	 # you should specify uri()
	 my $soap = SOAP::Lite
	   -> uri('http://my.own.site/CLASS') # <<< CLASS goes here
	   # ..... other parameters
	 ;
	 my $obj = $soap->call(new => @parameters)->result;
	 print $soap->call(method => $obj)->result;
	 # $obj object will be updated here if necessary,
	 # as if you call $obj->method() and method() updates $obj
	 # Update of modified object MAY not work if server on another side
	 # is not SOAP::Lite

This is clear until it calls the "method" method, and I want to make sure I
understand it fully.

This is what I understand so far, please correct me if I am confused:
   (1) $soap is obviously a reference to a blessed SOAP::Lite object and
remains so.

   (2) $obj is an actual object (reference) of the server-side class "CLASS".

   (3) The new() method of CLASS is invoked very similar to:
         (a) my $obj = CLASS->new(@parameters);
       because you do not have to pass the object as the first parameter.

   (4) The method() method of $obj (blessed CLASS) is invoked somehow
differently, sort of like:
         (b) CLASS::method($obj, @parameters);
       even though the call() syntax looks like (a) above, suggesting it
means this:
         (c) CLASS->method($obj, @parameters);
       or maybe
         (d) $obj->method($obj, @parameters);

The reason I ask is because the interface is the same for Class methods (3)
and Object methods (4) but the only code that seems like it would work in
normal perl is (a) and (b). Still, it looks like either (c) or (d) is really
being called for Object methods.

Is SOAP::Lite doing some kind of argument-munging magic on the server side
in the Object method cases?
Please help me understand how this OO-syntax call method works, so I can
avoid autodispatch if possible.

Thanks a lot,
Mike

Hi, Michael!

--- Michael Percy <mpercy@...> wrote:
>  my $obj = $soap->call(new => @parameters)->result;
>  print $soap->call(method => $obj)->result;
>  # $obj object will be updated here if necessary,
>  # as if you call $obj->method() and method() updates $obj
>  # Update of modified object MAY not work if server on another side
>
>  # is not SOAP::Lite
>
> This is clear until it calls the "method" method, and I want to
> make sure I understand it fully.
That basically means that execution of any method call MAY have a
side effect as modification of object itself:

$a = bless {a => 1} => 'A';
$a->update_a(2);

say will update property 'a' and return old value '1'.

In SOAP call you will see only result '1', but you're loosing side
effect. SOAP::Lite executes this code on server side as:

   $a->update_a(2); # regardless of using mode on client,
                    # autodispatch or ->call() interface

AND it'll also return modified object back, so your application will
see $a as modified object. Other SOAP implementations WILL NOT return
you object back, so you're loosing this side effect. It is NOT a
problem if you application returns object itself on any property
modifications (as SOAP::Lite does ;)), because then object will be
returned as a result and you can write:

$a = $a->update_a(2);

to get desired effect.

>   (1) $soap is obviously a reference to a blessed SOAP::Lite object
> and remains so.
Correct.

>   (2) $obj is an actual object (reference) of the server-side class
> "CLASS".
$obj is something returned by server that is blessed into class
CLASS.

>   (3) The new() method of CLASS is invoked very similar to:
>         (a) my $obj = CLASS->new(@parameters);
>       because you do not have to pass the object as the first
> parameter.
Correct. Here is the small difference comparing to what Perl does.
SOAP::Lite DOES NOT pass class name as the first parameter during
this call. This information is extracted on server side from URI and
call is still executed as CLASS method call: CLASS->method

>   (4) The method() method of $obj (blessed CLASS) is invoked
> somehow differently, sort of like:
>         (b) CLASS::method($obj, @parameters);
>       even though the call() syntax looks like (a) above,
> suggesting it means this:
>         (c) CLASS->method($obj, @parameters);
>       or maybe
>         (d) $obj->method($obj, @parameters);
It's always invoked as

   $obj->method(@parameters);

Let me know if something is still unclear, I'll give you more
details.

On related side. I plan to introduce option on client and server side
that will allow you to execute calls "as is" on server side, without
any parameters modifications. It'll allow you to do direct calls for
functions (it require wrappers right now, because all calls are
method calls) and allow to implement remote inheritance.

Best wishes, Paul.

--- Michael Percy <mpercy@...> wrote:
> Hello,
> I have a question about Persistent server-side objects without
> using the
> autodispatch mode.
>
> In the SOAP::Lite POD Docs, it says, under "implementation of OO
> interface"
> that you can have a remote object on the server as well as make
> local calls
> to it using the alternative "call" interface. I have pasted the
> example for
> using the call() interface below:
>
>  # you should specify uri()
>  my $soap = SOAP::Lite
> 	  -> uri('http://my.own.site/CLASS') # <<< CLASS goes here
> 	  # ..... other parameters
>  ;
>  my $obj = $soap->call(new => @parameters)->result;
>  print $soap->call(method => $obj)->result;
>  # $obj object will be updated here if necessary,
>  # as if you call $obj->method() and method() updates $obj
>  # Update of modified object MAY not work if server on another side
>
>  # is not SOAP::Lite
>
> This is clear until it calls the "method" method, and I want to
> make sure I understand it fully.
>
> This is what I understand so far, please correct me if I am
> confused:
>   (1) $soap is obviously a reference to a blessed SOAP::Lite object
> and
> remains so.
>
>   (2) $obj is an actual object (reference) of the server-side class
> "CLASS".
>
>   (3) The new() method of CLASS is invoked very similar to:
>         (a) my $obj = CLASS->new(@parameters);
>       because you do not have to pass the object as the first
> parameter.
>
>   (4) The method() method of $obj (blessed CLASS) is invoked
> somehow
> differently, sort of like:
>         (b) CLASS::method($obj, @parameters);
>       even though the call() syntax looks like (a) above,
> suggesting it
> means this:
>         (c) CLASS->method($obj, @parameters);
>       or maybe
>         (d) $obj->method($obj, @parameters);
>
> The reason I ask is because the interface is the same for Class
> methods (3)
> and Object methods (4) but the only code that seems like it would
> work in
> normal perl is (a) and (b). Still, it looks like either (c) or (d)
> is really
> being called for Object methods.
>
> Is SOAP::Lite doing some kind of argument-munging magic on the
> server side
> in the Object method cases?
> Please help me understand how this OO-syntax call method works, so
> I can
> avoid autodispatch if possible.
>
> Thanks a lot,
> Mike
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Paul,
Thanks for all your help, that was useful... But the main question I had was
related to these statements in the example:

	 my $obj = $soap->call(new => @parameters)->result;
	 print $soap->call(method => $obj)->result;

How would I pass parameters to the object method call in the 2nd line? If I
just pass them in as parameters after the object reference, then how does
SOAP::Lite know I want it to use the object as the "invoker" for the method
call instead of just using it as the first argument to a class method call
from URI?

Also, on a semi-related note, you gave me another question :) ...

> you object back, so you're loosing this side effect. It is NOT a
> problem if you application returns object itself on any property
> modifications (as SOAP::Lite does ;)), because then object will be
> returned as a result and you can write:
>
> $a = $a->update_a(2);

In this situation, how would you get the result of the method call itself
after doing this? just $a->result ?

What if you are using the call() syntax? Similar code? (I'd like to write
wrappers and factories for my soap objects that are also interoperable with
apache soap, possibly client and server.)

Thanks again!
Mike


> -----Original Message-----
> From: Paul Kulchenko [mailto:paulclinger@...]
> Sent: Friday, August 03, 2001 1:35 PM
> To: soaplite@yahoogroups.com
> Subject: Re: [soaplite] Persistent objects using call() syntax
>
>
> Hi, Michael!
>
> --- Michael Percy <mpercy@...> wrote:
> >  my $obj = $soap->call(new => @parameters)->result;
> >  print $soap->call(method => $obj)->result;
> >  # $obj object will be updated here if necessary,
> >  # as if you call $obj->method() and method() updates $obj
> >  # Update of modified object MAY not work if server on
> another side
> >
> >  # is not SOAP::Lite
> >
> > This is clear until it calls the "method" method, and I want to
> > make sure I understand it fully.
> That basically means that execution of any method call MAY have a
> side effect as modification of object itself:
>
> $a = bless {a => 1} => 'A';
> $a->update_a(2);
>
> say will update property 'a' and return old value '1'.
>
> In SOAP call you will see only result '1', but you're loosing side
> effect. SOAP::Lite executes this code on server side as:
>
>   $a->update_a(2); # regardless of using mode on client,
>                    # autodispatch or ->call() interface
>
> AND it'll also return modified object back, so your application will
> see $a as modified object. Other SOAP implementations WILL NOT return
> you object back, so you're loosing this side effect. It is NOT a
> problem if you application returns object itself on any property
> modifications (as SOAP::Lite does ;)), because then object will be
> returned as a result and you can write:
>
> $a = $a->update_a(2);
>
> to get desired effect.
>
> >   (1) $soap is obviously a reference to a blessed SOAP::Lite object
> > and remains so.
> Correct.
>
> >   (2) $obj is an actual object (reference) of the server-side class
> > "CLASS".
> $obj is something returned by server that is blessed into class
> CLASS.
>
> >   (3) The new() method of CLASS is invoked very similar to:
> >         (a) my $obj = CLASS->new(@parameters);
> >       because you do not have to pass the object as the first
> > parameter.
> Correct. Here is the small difference comparing to what Perl does.
> SOAP::Lite DOES NOT pass class name as the first parameter during
> this call. This information is extracted on server side from URI and
> call is still executed as CLASS method call: CLASS->method
>
> >   (4) The method() method of $obj (blessed CLASS) is invoked
> > somehow differently, sort of like:
> >         (b) CLASS::method($obj, @parameters);
> >       even though the call() syntax looks like (a) above,
> > suggesting it means this:
> >         (c) CLASS->method($obj, @parameters);
> >       or maybe
> >         (d) $obj->method($obj, @parameters);
> It's always invoked as
>
>   $obj->method(@parameters);
>
> Let me know if something is still unclear, I'll give you more
> details.
>
> On related side. I plan to introduce option on client and server side
> that will allow you to execute calls "as is" on server side, without
> any parameters modifications. It'll allow you to do direct calls for
> functions (it require wrappers right now, because all calls are
> method calls) and allow to implement remote inheritance.
>
> Best wishes, Paul.
>

Hi, Michael!

--- Michael Percy <mpercy@...> wrote:
> Thanks for all your help, that was useful... But the main question
> I had was
> related to these statements in the example:
>
>  my $obj = $soap->call(new => @parameters)->result;
>  print $soap->call(method => $obj)->result;
>
> How would I pass parameters to the object method call in the 2nd
> line? If I
$soap->call(method => $obj, @parameters)->result;

> just pass them in as parameters after the object reference, then
> how does
> SOAP::Lite know I want it to use the object as the "invoker" for
> the method
> call instead of just using it as the first argument to a class
> method call from URI?
Good question. I'm checking the first parameter and compare it with
CLASS info provided in URI. If it's object of correcponding type, I'm
making an object call, if not, class call with provided class info.

> > $a = $a->update_a(2);
>
> In this situation, how would you get the result of the method call
> itself after doing this? just $a->result ?
It IS the result. I gave you an example in autodispatch syntax.
Summary:

AD:

1. update_a returns OLD value:

   $value = $a->update_a(2);

object $a is ALSO updated if server is SOAP::Lite implementation

2. update_a returns modified object:

   $a = $a->update_a(2);

object $a is updated regardless of server implementation, because it
IS the result itself.

OO:

1. update_a returns OLD value:

   $value = $soap->call(update_a => $a, 2)->result;

again, object $a is updated if server is SOAP::Lite implementation

2. update_a returns modified object:

   $a = $soap->call(update_a => $a, 2)->result;

again, object $a is updated regardless of server implementation,
because it IS the result itself.

> What if you are using the call() syntax? Similar code? (I'd like to
> write
> wrappers and factories for my soap objects that are also
> interoperable with apache soap, possibly client and server.)
The only piece that is not interoperable is the magic that updates an
object itself as a side effect (AD.1. and OO.1.). Everything else
should work with any implementations (as soon as object
representations are similar on wire).

Let me know if you face any problems.

Best wishes, Paul.

> > -----Original Message-----
> > From: Paul Kulchenko [mailto:paulclinger@...]
> > Sent: Friday, August 03, 2001 1:35 PM
> > To: soaplite@yahoogroups.com
> > Subject: Re: [soaplite] Persistent objects using call() syntax
> >
> >
> > Hi, Michael!
> >
> > --- Michael Percy <mpercy@...> wrote:
> > >  my $obj = $soap->call(new => @parameters)->result;
> > >  print $soap->call(method => $obj)->result;
> > >  # $obj object will be updated here if necessary,
> > >  # as if you call $obj->method() and method() updates $obj
> > >  # Update of modified object MAY not work if server on
> > another side
> > >
> > >  # is not SOAP::Lite
> > >
> > > This is clear until it calls the "method" method, and I want to
> > > make sure I understand it fully.
> > That basically means that execution of any method call MAY have a
> > side effect as modification of object itself:
> >
> > $a = bless {a => 1} => 'A';
> > $a->update_a(2);
> >
> > say will update property 'a' and return old value '1'.
> >
> > In SOAP call you will see only result '1', but you're loosing
> side
> > effect. SOAP::Lite executes this code on server side as:
> >
> >   $a->update_a(2); # regardless of using mode on client,
> >                    # autodispatch or ->call() interface
> >
> > AND it'll also return modified object back, so your application
> will
> > see $a as modified object. Other SOAP implementations WILL NOT
> return
> > you object back, so you're loosing this side effect. It is NOT a
> > problem if you application returns object itself on any property
> > modifications (as SOAP::Lite does ;)), because then object will
> be
> > returned as a result and you can write:
> >
> > $a = $a->update_a(2);
> >
> > to get desired effect.
> >
> > >   (1) $soap is obviously a reference to a blessed SOAP::Lite
> object
> > > and remains so.
> > Correct.
> >
> > >   (2) $obj is an actual object (reference) of the server-side
> class
> > > "CLASS".
> > $obj is something returned by server that is blessed into class
> > CLASS.
> >
> > >   (3) The new() method of CLASS is invoked very similar to:
> > >         (a) my $obj = CLASS->new(@parameters);
> > >       because you do not have to pass the object as the first
> > > parameter.
> > Correct. Here is the small difference comparing to what Perl
> does.
> > SOAP::Lite DOES NOT pass class name as the first parameter during
> > this call. This information is extracted on server side from URI
> and
> > call is still executed as CLASS method call: CLASS->method
> >
> > >   (4) The method() method of $obj (blessed CLASS) is invoked
> > > somehow differently, sort of like:
> > >         (b) CLASS::method($obj, @parameters);
> > >       even though the call() syntax looks like (a) above,
> > > suggesting it means this:
> > >         (c) CLASS->method($obj, @parameters);
> > >       or maybe
> > >         (d) $obj->method($obj, @parameters);
> > It's always invoked as
> >
> >   $obj->method(@parameters);
> >
> > Let me know if something is still unclear, I'll give you more
> > details.
> >
> > On related side. I plan to introduce option on client and server
> side
> > that will allow you to execute calls "as is" on server side,
> without
> > any parameters modifications. It'll allow you to do direct calls
> for
> > functions (it require wrappers right now, because all calls are
> > method calls) and allow to implement remote inheritance.
> >
> > Best wishes, Paul.
> >
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Paul,
You're awesome! Thanks for your patience in answering all my questions.

Regards,
Mike

> -----Original Message-----
> From: Paul Kulchenko [mailto:paulclinger@...]
> Sent: Friday, August 03, 2001 3:28 PM
> To: soaplite@yahoogroups.com
> Subject: RE: [soaplite] Persistent objects using call() syntax
>
>
> Hi, Michael!
>
> --- Michael Percy <mpercy@...> wrote:
> > Thanks for all your help, that was useful... But the main question
> > I had was
> > related to these statements in the example:
> >
> >  my $obj = $soap->call(new => @parameters)->result;
> >  print $soap->call(method => $obj)->result;
> >
> > How would I pass parameters to the object method call in the 2nd
> > line? If I
> $soap->call(method => $obj, @parameters)->result;
>
> > just pass them in as parameters after the object reference, then
> > how does
> > SOAP::Lite know I want it to use the object as the "invoker" for
> > the method
> > call instead of just using it as the first argument to a class
> > method call from URI?
> Good question. I'm checking the first parameter and compare it with
> CLASS info provided in URI. If it's object of correcponding type, I'm
> making an object call, if not, class call with provided class info.
>
> > > $a = $a->update_a(2);
> >
> > In this situation, how would you get the result of the method call
> > itself after doing this? just $a->result ?
> It IS the result. I gave you an example in autodispatch syntax.
> Summary:
>
> AD:
>
> 1. update_a returns OLD value:
>
>   $value = $a->update_a(2);
>
> object $a is ALSO updated if server is SOAP::Lite implementation
>
> 2. update_a returns modified object:
>
>   $a = $a->update_a(2);
>
> object $a is updated regardless of server implementation, because it
> IS the result itself.
>
> OO:
>
> 1. update_a returns OLD value:
>
>   $value = $soap->call(update_a => $a, 2)->result;
>
> again, object $a is updated if server is SOAP::Lite implementation
>
> 2. update_a returns modified object:
>
>   $a = $soap->call(update_a => $a, 2)->result;
>
> again, object $a is updated regardless of server implementation,
> because it IS the result itself.
>
> > What if you are using the call() syntax? Similar code? (I'd like to
> > write
> > wrappers and factories for my soap objects that are also
> > interoperable with apache soap, possibly client and server.)
> The only piece that is not interoperable is the magic that updates an
> object itself as a side effect (AD.1. and OO.1.). Everything else
> should work with any implementations (as soon as object
> representations are similar on wire).
>
> Let me know if you face any problems.
>
> Best wishes, Paul.
>
> > > -----Original Message-----
> > > From: Paul Kulchenko [mailto:paulclinger@...]
> > > Sent: Friday, August 03, 2001 1:35 PM
> > > To: soaplite@yahoogroups.com
> > > Subject: Re: [soaplite] Persistent objects using call() syntax
> > >
> > >
> > > Hi, Michael!
> > >
> > > --- Michael Percy <mpercy@...> wrote:
> > > >  my $obj = $soap->call(new => @parameters)->result;
> > > >  print $soap->call(method => $obj)->result;
> > > >  # $obj object will be updated here if necessary,
> > > >  # as if you call $obj->method() and method()
> updates $obj
> > > >  # Update of modified object MAY not work if server on
> > > another side
> > > >
> > > >  # is not SOAP::Lite
> > > >
> > > > This is clear until it calls the "method" method, and I want to
> > > > make sure I understand it fully.
> > > That basically means that execution of any method call MAY have a
> > > side effect as modification of object itself:
> > >
> > > $a = bless {a => 1} => 'A';
> > > $a->update_a(2);
> > >
> > > say will update property 'a' and return old value '1'.
> > >
> > > In SOAP call you will see only result '1', but you're loosing
> > side
> > > effect. SOAP::Lite executes this code on server side as:
> > >
> > >   $a->update_a(2); # regardless of using mode on client,
> > >                    # autodispatch or ->call() interface
> > >
> > > AND it'll also return modified object back, so your application
> > will
> > > see $a as modified object. Other SOAP implementations WILL NOT
> > return
> > > you object back, so you're loosing this side effect. It is NOT a
> > > problem if you application returns object itself on any property
> > > modifications (as SOAP::Lite does ;)), because then object will
> > be
> > > returned as a result and you can write:
> > >
> > > $a = $a->update_a(2);
> > >
> > > to get desired effect.
> > >
> > > >   (1) $soap is obviously a reference to a blessed SOAP::Lite
> > object
> > > > and remains so.
> > > Correct.
> > >
> > > >   (2) $obj is an actual object (reference) of the server-side
> > class
> > > > "CLASS".
> > > $obj is something returned by server that is blessed into class
> > > CLASS.
> > >
> > > >   (3) The new() method of CLASS is invoked very similar to:
> > > >         (a) my $obj = CLASS->new(@parameters);
> > > >       because you do not have to pass the object as the first
> > > > parameter.
> > > Correct. Here is the small difference comparing to what Perl
> > does.
> > > SOAP::Lite DOES NOT pass class name as the first parameter during
> > > this call. This information is extracted on server side from URI
> > and
> > > call is still executed as CLASS method call: CLASS->method
> > >
> > > >   (4) The method() method of $obj (blessed CLASS) is invoked
> > > > somehow differently, sort of like:
> > > >         (b) CLASS::method($obj, @parameters);
> > > >       even though the call() syntax looks like (a) above,
> > > > suggesting it means this:
> > > >         (c) CLASS->method($obj, @parameters);
> > > >       or maybe
> > > >         (d) $obj->method($obj, @parameters);
> > > It's always invoked as
> > >
> > >   $obj->method(@parameters);
> > >
> > > Let me know if something is still unclear, I'll give you more
> > > details.
> > >
> > > On related side. I plan to introduce option on client and server
> > side
> > > that will allow you to execute calls "as is" on server side,
> > without
> > > any parameters modifications. It'll allow you to do direct calls
> > for
> > > functions (it require wrappers right now, because all calls are
> > > method calls) and allow to implement remote inheritance.
> > >
> > > Best wishes, Paul.
> > >
> >
>

Is there a way to force a string to be encoded in base64 using XMLRPC::Lite?

With very large string, the XML Parser seems to take forever.

Thanks

-Mathieu

try $data = SOAP::Data->type(base64 => $data);

where $data is the string you want encoded.

Peace,

Dave.

-----Original Message-----
From: soaplite@yahoogroups.com [mailto:soaplite@yahoogroups.com]
Sent: Monday, August 06, 2001 10:07 AM
To: soaplite@yahoogroups.com
Subject: [soaplite] forcing base64 in XMLRPC::Lite
Importance: Low


Is there a way to force a string to be encoded in base64 using
XMLRPC::Lite?

With very large string, the XML Parser seems to take forever.

Thanks

-Mathieu



To unsubscribe from this group, send an email to:
soaplite-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Hi, David!

> try $data = SOAP::Data->type(base64 => $data);
Correct. For XMLRPC, XMLRPC::Data synonim can be used. If you want to
use module on server side that works with both XMLRPC and SOAP
protocols, than you can safely use SOAP::Data and it'll work in
SOAP::Lite and XMLRPC::Lite.

Best wishes, Paul.

--- David Mullens <damullens@...> wrote:
> try $data = SOAP::Data->type(base64 => $data);
>
> where $data is the string you want encoded.
>
> Peace,
>
> Dave.
>
> -----Original Message-----
> From: soaplite@yahoogroups.com [mailto:soaplite@yahoogroups.com]
> Sent: Monday, August 06, 2001 10:07 AM
> To: soaplite@yahoogroups.com
> Subject: [soaplite] forcing base64 in XMLRPC::Lite
> Importance: Low
>
>
> Is there a way to force a string to be encoded in base64 using
> XMLRPC::Lite?
>
> With very large string, the XML Parser seems to take forever.
>
> Thanks
>
> -Mathieu
>
>
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

That helps, but the performance is still sucky. Alhough most of it is due to the
XML parser. Maybe I'll just rewrite the serializer for XMLRPC::Lite to a format
that's easier to parse. Non-portable, but what the heck, I need speed and I
control both ends for now.

The same data set (4.2Mb) takes >60 seconds in XMLRPC embedded as a string, 18
seconds as a base64, and 4 seconds with some simple text interface instead of
XML-RPC. Clearly, expat is the bottle neck.

Is there a way to force SOAP::Lite to use XML::Parser::Lite? Would that be
faster?

Those times are from starting the client to receiving the answer. The client and
the server run on the same machine.

-Mathieu

--- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
> Hi, David!
>
> > try $data = SOAP::Data->type(base64 => $data);
> Correct. For XMLRPC, XMLRPC::Data synonim can be used. If you want to
> use module on server side that works with both XMLRPC and SOAP
> protocols, than you can safely use SOAP::Data and it'll work in
> SOAP::Lite and XMLRPC::Lite.
>
> Best wishes, Paul.
>
> --- David Mullens <damullens@l...> wrote:
> > try $data = SOAP::Data->type(base64 => $data);
> >
> > where $data is the string you want encoded.
> >
> > Peace,
> >
> > Dave.
> >
> > -----Original Message-----
> > From: soaplite@y... [mailto:soaplite@y...]
> > Sent: Monday, August 06, 2001 10:07 AM
> > To: soaplite@y...
> > Subject: [soaplite] forcing base64 in XMLRPC::Lite
> > Importance: Low
> >
> >
> > Is there a way to force a string to be encoded in base64 using
> > XMLRPC::Lite?
> >
> > With very large string, the XML Parser seems to take forever.
> >
> > Thanks
> >
> > -Mathieu
> >
> >
> >
> > To unsubscribe from this group, send an email to:
> > soaplite-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> >
> > To unsubscribe from this group, send an email to:
> > soaplite-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/

Hi all,
I got the certificate authentication working but in unix only for now. I
have had some problems installing Crypt::SSLeay 0.29 in windows.
The 0.29 version doesn't support setting password for the private key, gives
you a prompt, so I had to make a small patch.
To use the certificates you need to set 3 environment vars. HTTPS_CERT_FILE,
HTTPS_KEY_FILE, HTTPS_CERT_PASS. (CERT_FILE, and KEY_FILE are often the same
file) Everything else will be taken care of by the Crypt::SSLeay module.

Hope it helps.
-Taras

Here is the simple patch(needed only if you using encripted private key, and
don't want a user prompt).

use Net::SSL;
package Net::SSL;
use GC::Cert;
sub configure_certs {
     my $self = shift;
     my $ctx = *$self->{ssl_ctx};
     my $c_pass= $ENV{'HTTPS_CERT_PASS'};
     eval{

if($c_pass){GC::Cert::SSL_CTX_set_default_passwd_cb_userdata($ctx,$c_pass);}
     };
     if($@){ print "\nNet:SSL Error:".$@."\n"; }
     my $count = 0;
     for ('HTTPS_CERT_FILE', 'HTTPS_KEY_FILE') {
         my $file = $ENV{$_};
         if($file) {
             (-e $file) or die("$file file does not exist: $!");
             $count++;
             if (/CERT/) {
                 $ctx->use_certificate_file($file ,1) || die("failed to load
$file: $!");
             } elsif (/KEY/) {
                 $ctx->use_PrivateKey_file($file, 1) || die("failed to load
$file: $!");
             } else {
                 die("setting $_ not supported");
             }
         }
     }

     # if both configs are set, then verify them
     if (($count == 2)) {
         if (! $ctx->check_private_key) {
             die("Private key and certificate do not match");
         }
     }

     $count; # number of successful cert loads/checks
}



Here is the xs file for actually setting the password.
#ifdef __cplusplus
extern "C" {
#endif
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"

/* ssl.h or openssl/ssl.h is included from the crypt_ssleay_version
  * file which is written when building with perl Makefile.PL
  * #include "ssl.h"
  */
#include "openssl/ssl.h"

#ifdef __cplusplus
}
#endif


MODULE = GC::Cert               PACKAGE = GC::Cert
PROTOTYPES: DISABLE
void
SSL_CTX_set_default_passwd_cb_userdata(ctx, pass)
         SSL_CTX* ctx
         char* pass


here is Cert.pm
package GC::Cert;

require 5.005_62;
use strict;
use warnings;

require Exporter;
require DynaLoader;

our @ISA = qw(Exporter DynaLoader);

# Items to export into callers namespace by default. Note: do not export
# names by default without a very good reason. Use EXPORT_OK instead.
# Do not simply export all your public functions/methods/constants.

# This allows declaration       use GC::Cert ':all';
# If you do not need this, moving things directly into @EXPORT or @EXPORT_OK
# will save memory.
our %EXPORT_TAGS = ( 'all' => [ qw(

) ] );

our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );

our @EXPORT = qw(

);
our $VERSION = '0.01';

bootstrap GC::Cert $VERSION;

# Preloaded methods go here.

1;

Hi, Mathieu!

> Is there a way to force SOAP::Lite to use XML::Parser::Lite? Would
> that be faster?
Yes, you can do it with $SOAP::Constants::DO_NOT_USE_XML_PARSER = 1;
somewhere after 'use SOAP::Lite', but before actual calls.

I don't think it'll make a difference for you and here is why:
> The same data set (4.2Mb) takes >60 seconds in XMLRPC embedded as a
> string, 18 seconds as a base64, and 4 seconds with some simple text
> interface instead of XML-RPC. Clearly, expat is the bottle neck.
Such a big difference between text and base64 strings may occur only
if your string has many character entities. XML::Parser generates
lots of events in this case where every entity generate their own
callback. Parsing is quick, but it requires a lot of memory
processing (even if it's just a concatenation). base64 encoding
doesn't have this overhead. I believe it's covered with some details
in PERFORMANCE section in SOAP::Lite doc.

> is due to the XML parser. Maybe I'll just rewrite the serializer
> for XMLRPC::Lite to a format that's easier to parse. Non-portable,
> but what the heck, I need speed and I control both ends for now.
There is nothing wrong with that. SOAP::Lite provides you ability to
plug your serializer, deserializer, parser, transports and everything
else. In fact, I was thinking about it myself. I would like to
provide set of deserializers, optimized for speed, memory, feature
set, etc.

Best wishes, Paul.

--- mrdamnfrenchy@... wrote:
> That helps, but the performance is still sucky. Alhough most of it
> is due to the XML parser. Maybe I'll just rewrite the serializer
> for XMLRPC::Lite to a format that's easier to parse. Non-portable,
> but what the heck, I need speed and I control both ends for now.
>
> The same data set (4.2Mb) takes >60 seconds in XMLRPC embedded as a
> string, 18 seconds as a base64, and 4 seconds with some simple text
> interface instead of XML-RPC. Clearly, expat is the bottle neck.
>
> Is there a way to force SOAP::Lite to use XML::Parser::Lite? Would
> that be faster?
>
> Those times are from starting the client to receiving the answer.
> The client and the server run on the same machine.
>
> -Mathieu
>
> --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:
> > Hi, David!
> >
> > > try $data = SOAP::Data->type(base64 => $data);
> > Correct. For XMLRPC, XMLRPC::Data synonim can be used. If you
> want to
> > use module on server side that works with both XMLRPC and SOAP
> > protocols, than you can safely use SOAP::Data and it'll work in
> > SOAP::Lite and XMLRPC::Lite.
> >
> > Best wishes, Paul.
> >
> > --- David Mullens <damullens@l...> wrote:
> > > try $data = SOAP::Data->type(base64 => $data);
> > >
> > > where $data is the string you want encoded.
> > >
> > > Peace,
> > >
> > > Dave.
> > >
> > > -----Original Message-----
> > > From: soaplite@y... [mailto:soaplite@y...]
> > > Sent: Monday, August 06, 2001 10:07 AM
> > > To: soaplite@y...
> > > Subject: [soaplite] forcing base64 in XMLRPC::Lite
> > > Importance: Low
> > >
> > >
> > > Is there a way to force a string to be encoded in base64 using
> > > XMLRPC::Lite?
> > >
> > > With very large string, the XML Parser seems to take forever.
> > >
> > > Thanks
> > >
> > > -Mathieu
> > >
> > >
> > >
> > > To unsubscribe from this group, send an email to:
> > > soaplite-unsubscribe@y...
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> > > http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
> > >
> > > ------------------------ Yahoo! Groups Sponsor
> > >
> > > To unsubscribe from this group, send an email to:
> > > soaplite-unsubscribe@y...
> > >
> > >
> > >
> > > Your use of Yahoo! Groups is subject to
> > > http://docs.yahoo.com/info/terms/
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Make international calls for as low as $.04/minute with Yahoo!
> Messenger
> > http://phonecard.yahoo.com/
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Hi Paul,

I did force to use XML::Parser::Lite, and that made a huge difference. Encoded
as a string, it now takes 5.3 seconds instead of 18 seconds. Encoding it as a
base64 is a bit slower (6.5 seconds).

So at least it's in the ball park as a custom solution, which is a lot better.

-Mathieu

> > Is there a way to force SOAP::Lite to use XML::Parser::Lite? Would
> > that be faster?
> Yes, you can do it with $SOAP::Constants::DO_NOT_USE_XML_PARSER = 1;
> somewhere after 'use SOAP::Lite', but before actual calls.
>
> I don't think it'll make a difference for you and here is why:
> > The same data set (4.2Mb) takes >60 seconds in XMLRPC embedded as a
> > string, 18 seconds as a base64, and 4 seconds with some simple text
> > interface instead of XML-RPC. Clearly, expat is the bottle neck.

> So at least it's in the ball park as a custom solution, which is a
> lot better.
True, it could make a difference sometimes, esp. for CGI apps,
because it doesn't need to initiate XML::Parser. yet keep in mind
that XML::Parser::Lite doesn't do entity decoding, so you have to do
it on application level if you need to. Future versions may support
entity decoding. If you do base64 you shouldn't have any problem
though.

Best wishes, Paul.

--- mrdamnfrenchy@... wrote:
> Hi Paul,
>
> I did force to use XML::Parser::Lite, and that made a huge
> difference. Encoded as a string, it now takes 5.3 seconds instead
> of 18 seconds. Encoding it as a base64 is a bit slower (6.5
> seconds).
>
> So at least it's in the ball park as a custom solution, which is a
> lot better.
>
> -Mathieu
>
> > > Is there a way to force SOAP::Lite to use XML::Parser::Lite?
> Would
> > > that be faster?
> > Yes, you can do it with $SOAP::Constants::DO_NOT_USE_XML_PARSER =
> 1;
> > somewhere after 'use SOAP::Lite', but before actual calls.
> >
> > I don't think it'll make a difference for you and here is why:
> > > The same data set (4.2Mb) takes >60 seconds in XMLRPC embedded
> as a
> > > string, 18 seconds as a base64, and 4 seconds with some simple
> text
> > > interface instead of XML-RPC. Clearly, expat is the bottle
> neck.
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

hello

I need to send lists (string or structs) from a SOAP::Lite server to a
delphi 6 client. The client uses the wsdl to generate stubs.

How should I return my list server-side ?

   return @list;
   return \@list;
   return SOAP::Data->value(...);
   return SOAP::Data->value( { "list" => \@list } ); (!)

here is (part of) my wsdl as of now:

   <types>
     <xsd:schema targetNamespace="urn:MyStuff"
         xmlns:xsd="http://www.w3.org/1999/XMLSchema">
       <xsd:complexType name="UserList">
         <xsd:all>
           <xsd:element name="username" type="xsd:string"
                        minOccurs="0"
                        maxOccurs="unbounded" />
         </xsd:all>
       </xsd:complexType>
     </schema>
   </types>

   <message name="ListUsersRequest"/>
   <message name="ListUsersResponse">
     <part name="list" type="myTypes:UserList"/>
   </message>

What is my response supposed to look like ?
I'm completely stuck ... so thanks for any advice ...

   alex

i'm getting this weird error when i try to instantiate Lite.dll via
ASP.

here's the error:

Error Type:
Server object, ASP 0177 (0x80004005)
Unspecified error
/pa-soap/soapserver.asp, line 4

here's the asp soaplite server code:
line 4 is the call to CreateObject

any ideas?

<%
'switched this to html so i can see error in browser

'Response.ContentType = "text/xml"

Response.ContentType = "text/html"

Response.Write(Server.CreateObject("SOAP.Lite") _
         .server("SOAP::Server") _
         .dispatch_to("\SOAP\modules\","Demo") _
         .handle(Request.BinaryRead(Request.TotalBytes)))
%>

getting the following error using the SOAP::Lite
ASP/Lite.dll server

there seems to be a problem loading Lite.dll  i can
get this server code to work on some NT machines but
not my NT production machine.

Error Type:
Server object, ASP 0177 (0x80004005)
Unspecified error
/pa-soap/soapserver.asp, line 4

server code:

1 <%
2 Response.ContentType = "text/html"
3
4 Response.Write(Server.CreateObject("SOAP.Lite") _
         .server("SOAP::Server") _
         .dispatch_to("PA-SOAPmodules","Demo","PA") _

.handle(Request.BinaryRead(Request.TotalBytes)))
%>



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Hi, Marco!

> there seems to be a problem loading Lite.dll  i can
> get this server code to work on some NT machines but
> not my NT production machine.
> Server object, ASP 0177 (0x80004005)
This looks like a known error. Some info is here:
http://p2p.wrox.com/archive/proasp_howto/2001-02/40.asp

If you type 'ASP 0177:80004005' in Google you'll get a list of pages
that returned this error to Google! :)

Seems like a main reason for that is improper module/library
registration but there are not so many thing you can do wrong.
Unfortunately I can't be more helpful on that. Let me know if you
find any additional information or cause, I'll include it into the
documentation.

Best wishes, Paul.

--- Marco DiPlacido <mdiplacido@...> wrote:
> getting the following error using the SOAP::Lite
> ASP/Lite.dll server
>
> there seems to be a problem loading Lite.dll  i can
> get this server code to work on some NT machines but
> not my NT production machine.
>
> Error Type:
> Server object, ASP 0177 (0x80004005)
> Unspecified error
> /pa-soap/soapserver.asp, line 4
>
> server code:
>
> 1 <%
> 2 Response.ContentType = "text/html"
> 3
> 4 Response.Write(Server.CreateObject("SOAP.Lite") _
>         .server("SOAP::Server") _
>         .dispatch_to("PA-SOAPmodules","Demo","PA") _
>
> .handle(Request.BinaryRead(Request.TotalBytes)))
> %>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo!
> Messenger
> http://phonecard.yahoo.com/
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

what's going on here?   my Lite.dll "perl environment" is not working
on my production machine but, it works fine on my test box.

here's the error i'm getting:

SOAP-ENV:Client Failed to access class (PA): Can't locate DBI.pm in
@INC (@INC c
ontains: C:\TEMP\Lite\{7BF2021E-79FD-43D1-A860-DC4417EE9F43}\ . \PA-
SOAP\modules
\) at PA.pm line 3.
BEGIN failed--compilation aborted at PA.pm line 3.


i have module named PA which works fine standalone on my machine but,
when i try to call methods on it under a win2k ASP/Lite.dll server
it's almost as if the standard lib directories are not available.
what's going on!?   DBI is installed on the machine and it does work
on regular scripts.

Are you using dynamic dispatch for your module on the production box?

Try changing the "use DBI" to "require DBI" in your code... if that fixes
(or at least changes) the problem then that is probably the issue.

When using dynamic dispatch, @INC is disabled at compile time, but then
restored at run time, due to security reasons. You can also switch to static
dispatch to overcome this issue.

HTH,
Mike

> -----Original Message-----
> From: mdiplacido@... [mailto:mdiplacido@...]
> Sent: Tuesday, August 07, 2001 1:11 PM
> To: soaplite@yahoogroups.com
> Subject: [soaplite] more ASP / Lite.dll problems
>
>
> what's going on here?   my Lite.dll "perl environment" is not working
> on my production machine but, it works fine on my test box.
>
> here's the error i'm getting:
>
> SOAP-ENV:Client Failed to access class (PA): Can't locate DBI.pm in
> @INC (@INC c
> ontains: C:\TEMP\Lite\{7BF2021E-79FD-43D1-A860-DC4417EE9F43}\ . \PA-
> SOAP\modules
> \) at PA.pm line 3.
> BEGIN failed--compilation aborted at PA.pm line 3.
>
>
> i have module named PA which works fine standalone on my machine but,
> when i try to call methods on it under a win2k ASP/Lite.dll server
> it's almost as if the standard lib directories are not available.
> what's going on!?   DBI is installed on the machine and it does work
> on regular scripts.
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Small business owners...
> Tell us what you think!
> http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/W6uqlB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> soaplite-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Howdy,

I'm trying to learn how to use SOAP for sending and receiving complex data
types.  I've written the code below to use the multiple symbol realtime
quote service at XMLToday.com (see WSDL in code).  I've gotten almost
everything to work and then hit a brick wall.

The service request and response are both complex types.  In short, you send
a list of ticker symbols (wrapped in a complex structure) and the service
responds with multiple complex structures (one for each symbol in your list)
containing various data.  This works fine, with one exception:  I can only
get data for the last symbol in the list.

By running SOAP::Lite with +trace, I've verified that the service is
responding with multiple fragments (one for each symbol in $symbb) each of
which is named "stock_quote".  It looks like each one overwrites the
previous one in my result set.  I had expected (silly me) to be able to loop
over the returned hash reference (in $quotes) to get each one. I was wrong.
Dumping $quotes (Data::Dump) shows a blessed object containing only the data
for the last symbol.

I tried to use the paramsout method from the docs, but couldn't get it to
solve the problem.  I should mention that I'm fairly new to both SOAP and
Perl.  The former has been a great deal easier thanks to SOAP::Lite.
Excellent work Paul!

The (almost) working code is below.  Any thoughts?

Thanks,
David
---
--
-

## Code only prints data for last symbol (ADBE)
## can't figure out how to get data for other symbols
## returned by call.
##
use SOAP::Lite service =>
'http://services.xmltoday.com/vx_engine/wsdl_publish.vep/realtime.wsdl';
my $symbb = "MSFT+IBM+ADBE";
my @parameters = (
   SOAP::Data->name(stockticker => {symbol => "$symbb"})
);
my $quotes = getRTQuote(@parameters);
my $inlinet = "Info for $quotes->{stock_quote}->{'symbol'}:" .
	    "...Last Sale:  " . $quotes->{stock_quote}->{'last'};

print $inlinet;

so during complile time the DBI package is nowhere to be found!?
jeez.  okay, how do you enable static dispatch?

--- In soaplite@y..., Michael Percy <mpercy@p...> wrote:
> Are you using dynamic dispatch for your module on the production
box?
>
> Try changing the "use DBI" to "require DBI" in your code... if that
fixes
> (or at least changes) the problem then that is probably the issue.
>
> When using dynamic dispatch, @INC is disabled at compile time, but
then
> restored at run time, due to security reasons. You can also switch
to static
> dispatch to overcome this issue.
>
> HTH,
> Mike
>
> > -----Original Message-----
> > From: mdiplacido@y... [mailto:mdiplacido@y...]
> > Sent: Tuesday, August 07, 2001 1:11 PM
> > To: soaplite@y...
> > Subject: [soaplite] more ASP / Lite.dll problems
> >
> >
> > what's going on here?   my Lite.dll "perl environment" is not
working
> > on my production machine but, it works fine on my test box.
> >
> > here's the error i'm getting:
> >
> > SOAP-ENV:Client Failed to access class (PA): Can't locate DBI.pm
in
> > @INC (@INC c
> > ontains: C:\TEMP\Lite\{7BF2021E-79FD-43D1-A860-DC4417EE9F43}\ .
\PA-
> > SOAP\modules
> > \) at PA.pm line 3.
> > BEGIN failed--compilation aborted at PA.pm line 3.
> >
> >
> > i have module named PA which works fine standalone on my machine
but,
> > when i try to call methods on it under a win2k ASP/Lite.dll
server
> > it's almost as if the standard lib directories are not available.
> > what's going on!?   DBI is installed on the machine and it does
work
> > on regular scripts.
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~-->
> > Small business owners...
> > Tell us what you think!
> > http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/W6uqlB/TM
> > --------------------------------------------------------------
> > -------~->
> >
> > To unsubscribe from this group, send an email to:
> > soaplite-unsubscribe@y...
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/

Hi

Sorry if this is an easy question, I searched through the archives.
But I was looking for a more simple explanation. I have been working
with soap::lite for a few weeks now and I understand the basics of
it. But what I wanted to do was to have my server program send files
to the client, and client to server. I keep looking on line for
information on how to do this but can't find any good explanations. I
have read some stuff on attaching messages. And have also read some
things on MIME. I was wondering if any one could help me with an
explanation and an example.

Thanks for the help