soaplite-devel — SOAP::Lite developers

Re: [Soaplite-devel] SOAP::Lite development - next release

[Martin K. <mar...@fe...>]

Hi there,

thanks for all your remarks - I think I'm going to use the URL Robert
found for interop tests. Even if we would use soaplite.com, I guess
there won't be too many volunteers for keeping a bunch of different SOAP
servers (like listed on http://www.xmethods.net/ilab/) up and running.

For a starter, I'll just skip the test that fail for external reasons
(i.e. because the SOAP server queried does not return the expected
result but something else), and add improving the test suite to my list
of tasks.

Martin

Am Donnerstag, den 11.10.2007, 11:20 -0700 schrieb Paul Kulchenko:
> Robert,
> 
> > What if we attempt to connect to soaplite.com for a list of interop
> > tests?  If the connection fails, we get nothing to test and nothing
> > to fail, which seems like it mitigates (to a degree) the firewall
> > issue. 
> 
> This is actually exactly how it was done previously (and probably
> still is). If the connection fails then the test is skipped (for most
> if not all external tests). There is also a set of tests that runs on
> soaplite.com; it can be modified/expanded to match our requirements.
> 
> Paul.
> 
> --- Robert Landrum <rla...@ao...> wrote:
> 
> > David Bussenschutt wrote:
> > > Why not make the test suite have built-in test services, and
> > completely avoid external dependancies altogether.  
> > > 
> > > If it was me, I'd make a "fake soap server" testing tool, that
> > only knows how to respond to one specific request with one specific
> > "canned" response, and (in order to test alternate functionalities,
> > I'd make the "canned responses" exactly match those currently given
> > by services like weather, google, etc.   THis way, you get the
> > tests against "external" systems (via their canned "known
> > responses" saved to a local configuration) , and don't rely on the
> > 4external systems themselves being up.   It also means that the
> > tests work behind big/secure firewalls and on off-line systems.
> > > 
> > 
> > That works for testing the parsing of the responses from those
> > external 
> > services, but does not test the formatting of the original request.
> > 
> > That's actually an area that seems to be a bigger problem, at least
> > 
> > looking at the interop.soaplite.com page.  A cursory glance seems
> > to 
> > indicate that there are issues in the formatting of our initial 
> > requests...  of course this is a ancient version.
> > 
> > Just throwing out an idea...
> > 
> > What if we attempt to connect to soaplite.com for a list of interop
> > 
> > tests?  If the connection fails, we get nothing to test and nothing
> > to 
> > fail, which seems like it mitigates (to a degree) the firewall
> > issue. 
> > If a response is received, the interop test services can be parsed
> > out 
> > and tested.  This would mean that even when the interop services
> > change, 
> > we don't need to release a new version to correct the issue.
> > 
> > 
> > 
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Soaplite-devel mailing list
> > Soa...@li...
> > https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> > 
> 
> 
> 
>        
> ____________________________________________________________________________________
> Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
> http://sims.yahoo.com/  
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 

Re: [Soaplite-devel] SOAP::Lite development - next release

[Paul K. <pau...@ya...>]

Robert,

> What if we attempt to connect to soaplite.com for a list of interop
> tests?  If the connection fails, we get nothing to test and nothing
> to fail, which seems like it mitigates (to a degree) the firewall
> issue. 

This is actually exactly how it was done previously (and probably
still is). If the connection fails then the test is skipped (for most
if not all external tests). There is also a set of tests that runs on
soaplite.com; it can be modified/expanded to match our requirements.

Paul.

--- Robert Landrum <rla...@ao...> wrote:

> David Bussenschutt wrote:
> > Why not make the test suite have built-in test services, and
> completely avoid external dependancies altogether.  
> > 
> > If it was me, I'd make a "fake soap server" testing tool, that
> only knows how to respond to one specific request with one specific
> "canned" response, and (in order to test alternate functionalities,
> I'd make the "canned responses" exactly match those currently given
> by services like weather, google, etc.   THis way, you get the
> tests against "external" systems (via their canned "known
> responses" saved to a local configuration) , and don't rely on the
> 4external systems themselves being up.   It also means that the
> tests work behind big/secure firewalls and on off-line systems.
> > 
> 
> That works for testing the parsing of the responses from those
> external 
> services, but does not test the formatting of the original request.
> 
> That's actually an area that seems to be a bigger problem, at least
> 
> looking at the interop.soaplite.com page.  A cursory glance seems
> to 
> indicate that there are issues in the formatting of our initial 
> requests...  of course this is a ancient version.
> 
> Just throwing out an idea...
> 
> What if we attempt to connect to soaplite.com for a list of interop
> 
> tests?  If the connection fails, we get nothing to test and nothing
> to 
> fail, which seems like it mitigates (to a degree) the firewall
> issue. 
> If a response is received, the interop test services can be parsed
> out 
> and tested.  This would mean that even when the interop services
> change, 
> we don't need to release a new version to correct the issue.
> 
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

Re: [Soaplite-devel] SOAP::Lite development - next release

[Robert L. <rla...@ao...>]

David Bussenschutt wrote:
> Why not make the test suite have built-in test services, and completely avoid external dependancies altogether.  
> 
> If it was me, I'd make a "fake soap server" testing tool, that only knows how to respond to one specific request with one specific "canned" response, and (in order to test alternate functionalities, I'd make the "canned responses" exactly match those currently given by services like weather, google, etc.   THis way, you get the tests against "external" systems (via their canned "known responses" saved to a local configuration) , and don't rely on the 4external systems themselves being up.   It also means that the tests work behind big/secure firewalls and on off-line systems.
> 

That works for testing the parsing of the responses from those external 
services, but does not test the formatting of the original request. 
That's actually an area that seems to be a bigger problem, at least 
looking at the interop.soaplite.com page.  A cursory glance seems to 
indicate that there are issues in the formatting of our initial 
requests...  of course this is a ancient version.

Just throwing out an idea...

What if we attempt to connect to soaplite.com for a list of interop 
tests?  If the connection fails, we get nothing to test and nothing to 
fail, which seems like it mitigates (to a degree) the firewall issue. 
If a response is received, the interop test services can be parsed out 
and tested.  This would mean that even when the interop services change, 
we don't need to release a new version to correct the issue.

Re: [Soaplite-devel] SOAP::Lite development - next release

[David B. <Dav...@qm...>]

Why not make the test suite have built-in test services, and completely a=
void external dependancies altogether. =20

If it was me, I'd make a "fake soap server" testing tool, that only knows=
 how to respond to one specific request with one specific "canned" respon=
se, and (in order to test alternate functionalities, I'd make the "canned=
 responses" exactly match those currently given by services like weather,=
 google, etc.   THis way, you get the tests against "external" systems (v=
ia their canned "known responses" saved to a local configuration) , and d=
on't rely on the 4external systems themselves being up.   It also means t=
hat the tests work behind big/secure firewalls and on off-line systems.

Buzz.

-----Original Message-----
From: soa...@li...
[mailto:soa...@li...]On Behalf Of Robert
Landrum
Sent: Thursday, 11 October 2007 12:36 AM
To: Matthew Runo
Cc: soaplite-devel
Subject: Re: [Soaplite-devel] SOAP::Lite development - next release


Matthew Runo wrote:
> Yes, the test suite ran upon install has been failing for some time =20
> now. I've been ignoring it, and --force installing. I vote to remove =20
> it - add in a couple you know are live and go for it.
>=20

That's sort of the problem.  What is live, and what is going to be live=20
in perpetuity.

It's a trivial matter to test against local services, but more often=20
than not, I find services written in Java, C#, etc, to be incompatible=20
with the current SOAP::Lite implementation... And that just within my=20
organization.  :(

I found this...  http://www.xmethods.net/ilab/

I haven't looked at the test suite, so I'm not sure how many these are=20
actually being tested.

Rob

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Soaplite-devel mailing list
Soa...@li...
https://lists.sourceforge.net/lists/listinfo/soaplite-devel


The message and any attachment is confidential and may be privileged or o=
therwise protected from disclosure. If you have received it by mistake pl=
ease let us know by reply and then delete it from your system; you should=
 not copy the message or disclose its contents to anyone.

Re: [Soaplite-devel] SOAP::Lite development - next release

[Paul K. <pau...@ya...>]

> Maybe we could make the tests optional - and say what each test is 
> testing. That way, when 40% fail next year, I can see that X Y and

In fact, all external tests were supposed to be optional; with 'no'
as the default answer to the question on whether they need to be run
(to work properly for automated/CPAN installs). Not sure what was
changed to trigger those tests.

I agree with updating the test suite and removing everything that is
not currently working.

Paul.

--- mr...@za... wrote:

> Yes. Local services are, of course, better - but cannot be counted
> on  
> being available all the time when someone is installing SOAP::Lite.
> 
> Google has a good websearch API, I believe. Amazon has one too. I  
> believe there is a National Weather Service one too. Things like
> this  
> might be a good way to test an install, as they've been around for 
> 
> years, and are not likely to disappear in the near future. Of
> course,  
> nothing is 100%.
> 
> Maybe we could make the tests optional - and say what each test is 
> 
> testing. That way, when 40% fail next year, I can see that X Y and
> Z  
> are untested because they failed, but features A B and C should
> still  
> work fine.
> 
> --Matthew
> 
> Quoting Robert Landrum <rla...@ao...>:
> 
> > Matthew Runo wrote:
> >> Yes, the test suite ran upon install has been failing for some
> time  
> >>   now. I've been ignoring it, and --force installing. I vote to 
>  
> >> remove  it - add in a couple you know are live and go for it.
> >>
> >
> > That's sort of the problem.  What is live, and what is going to
> be live
> > in perpetuity.
> >
> > It's a trivial matter to test against local services, but more
> often
> > than not, I find services written in Java, C#, etc, to be
> incompatible
> > with the current SOAP::Lite implementation... And that just
> within my
> > organization.  :(
> >
> > I found this...  http://www.xmethods.net/ilab/
> >
> > I haven't looked at the test suite, so I'm not sure how many
> these are
> > actually being tested.
> >
> > Rob
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

Re: [Soaplite-devel] SOAP::Lite development - next release

[<mr...@za...>]

Yes. Local services are, of course, better - but cannot be counted on =20
being available all the time when someone is installing SOAP::Lite.

Google has a good websearch API, I believe. Amazon has one too. I =20
believe there is a National Weather Service one too. Things like this =20
might be a good way to test an install, as they've been around for =20
years, and are not likely to disappear in the near future. Of course, =20
nothing is 100%.

Maybe we could make the tests optional - and say what each test is =20
testing. That way, when 40% fail next year, I can see that X Y and Z =20
are untested because they failed, but features A B and C should still =20
work fine.

--Matthew

Quoting Robert Landrum <rla...@ao...>:

> Matthew Runo wrote:
>> Yes, the test suite ran upon install has been failing for some time =20
>>   now. I've been ignoring it, and --force installing. I vote to  =20
>> remove  it - add in a couple you know are live and go for it.
>>
>
> That's sort of the problem.  What is live, and what is going to be live
> in perpetuity.
>
> It's a trivial matter to test against local services, but more often
> than not, I find services written in Java, C#, etc, to be incompatible
> with the current SOAP::Lite implementation... And that just within my
> organization.  :(
>
> I found this...  http://www.xmethods.net/ilab/
>
> I haven't looked at the test suite, so I'm not sure how many these are
> actually being tested.
>
> Rob



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Soaplite-devel] SOAP::Lite development - next release

[Robert L. <rla...@ao...>]

Matthew Runo wrote:
> Yes, the test suite ran upon install has been failing for some time  
> now. I've been ignoring it, and --force installing. I vote to remove  
> it - add in a couple you know are live and go for it.
> 

That's sort of the problem.  What is live, and what is going to be live 
in perpetuity.

It's a trivial matter to test against local services, but more often 
than not, I find services written in Java, C#, etc, to be incompatible 
with the current SOAP::Lite implementation... And that just within my 
organization.  :(

I found this...  http://www.xmethods.net/ilab/

I haven't looked at the test suite, so I'm not sure how many these are 
actually being tested.

Rob

Re: [Soaplite-devel] SOAP::Lite development - next release

[Matthew R. <mr...@za...>]

Yes, the test suite ran upon install has been failing for some time  
now. I've been ignoring it, and --force installing. I vote to remove  
it - add in a couple you know are live and go for it.

+--------------------------------------------------------+
  | Matthew Runo
  | Zappos Development
  | mr...@za...
  | 702-943-7833
+--------------------------------------------------------+


On Oct 9, 2007, at 9:53 AM, Martin Kutter wrote:

> Hi there,
>
> the good news first: I think it's already time for a new release. It's
> mainly a bugfix release, but I think it would be nice to show the  
> world
> SOAP::Lite's still alive.
> Changes so far are:
>
> (+ means new feature, ! means bugfix, # are CPAN RT issues, [ 123456 ]
> SF.net bugs ):
>
>   + Added LOOPBACK test transport backend.
>   + Added more core tests
>   ! Fixed #14052: 'use base' pragma no longer works for SOAP::Lite
>   ! Fixed #27032: Some debugging-aid patches
>   ! Fixed #22732: Documentation error for use_prefix()
>   ! Fixed [ 1044270 ] Suppress type for array when autotyping off
>   ! Fixed [ 1665916 ] encode_scalar needs "no strict 'refs'"?
>   ! Fixed [ 1481017 ] Typo on CPAN's documentation
>   ! Fixed [ 1750846 ] Error with ENV{EXPECT}
>   ! Fixed [ 887015 ] Memory Leak
>   ! Fixed [ 1700326 ] encode_data called incorrectly in envelope
>   ! Fixed [ 1612405 ] Incorrect deserialization of arrays/vectors
>   ! Fixed [ 1204279 ] Boolean serialization error and added test
>   ! Fixed [ 1569418 ] anyURI Serialization problem
>
> The bad news are: The extended test suite does not work (or better:  
> does
> not seem to produce usable results).
> Without further investigation, it looks just like most of the web
> services accessed as test have closed down in the meantime or don't
> return the expected result (for example, the ActiveState WS returns
> something (a empty search response), but not the data expected.
>
> Has someone here tried the extended test suite lately? Any hints?
>
> If there's only similar experience, I'd just remove the "real world"
> SOAP tests, add one or to I know working and wrap everything up.
>
> Are there any places besides CPAN and sourceforge to put releases  
> onto?
>
> Thanks for your help,
>
> Martin
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>

[Soaplite-devel] SOAP::Lite development - next release

[Martin K. <mar...@fe...>]

Hi there,

the good news first: I think it's already time for a new release. It's
mainly a bugfix release, but I think it would be nice to show the world
SOAP::Lite's still alive.
Changes so far are:

(+ means new feature, ! means bugfix, # are CPAN RT issues, [ 123456 ]
SF.net bugs ):

  + Added LOOPBACK test transport backend.
  + Added more core tests
  ! Fixed #14052: 'use base' pragma no longer works for SOAP::Lite
  ! Fixed #27032: Some debugging-aid patches
  ! Fixed #22732: Documentation error for use_prefix()
  ! Fixed [ 1044270 ] Suppress type for array when autotyping off
  ! Fixed [ 1665916 ] encode_scalar needs "no strict 'refs'"?
  ! Fixed [ 1481017 ] Typo on CPAN's documentation
  ! Fixed [ 1750846 ] Error with ENV{EXPECT}
  ! Fixed [ 887015 ] Memory Leak
  ! Fixed [ 1700326 ] encode_data called incorrectly in envelope
  ! Fixed [ 1612405 ] Incorrect deserialization of arrays/vectors
  ! Fixed [ 1204279 ] Boolean serialization error and added test
  ! Fixed [ 1569418 ] anyURI Serialization problem

The bad news are: The extended test suite does not work (or better: does
not seem to produce usable results). 
Without further investigation, it looks just like most of the web
services accessed as test have closed down in the meantime or don't
return the expected result (for example, the ActiveState WS returns
something (a empty search response), but not the data expected.

Has someone here tried the extended test suite lately? Any hints?

If there's only similar experience, I'd just remove the "real world"
SOAP tests, add one or to I know working and wrap everything up.

Are there any places besides CPAN and sourceforge to put releases onto?

Thanks for your help,

Martin

Re: [Soaplite-devel] SOAP::Client

[Martin K. <mar...@fe...>]

Hi there,

As Rob pointed out, most new() methods currently do what I have proposed
(but at some other place).

As there's nobody here telling me that calling new() every time is
important, I'll just implement the proposed alternative.

Im not going to work over the whole SOAP-Lite package to make this
consistant, though - at least not now.

Thanks for your comments,

Martin

Am Donnerstag, den 04.10.2007, 12:44 +0200 schrieb Martin Kutter:
> Hi there,
> 
> around line 2250 in SOAP/Lite.pm, there's the package SOAP::Client.
> 
> It creates a bunch of setter/getter methods, like this:
> 
>  *$method = sub {
>    my $self = shift->new;
>    @_ 
> 	? ($self->{$field} = shift, return $self) 
> 	: return $self->{$field};
>  }
> 
> I stumbled across the first line of these methods today, when writing a
> loopback test transport backend: It calls the transport backend's new() 
> every time one of these methods is called, regardless of whether it's
> been called before.n
> 
> In my opinion, this introduces two misbehaviours:
> 
> a) the constructor new() is frequently called as an object method -
> which is a perlish, but nonetheless bad habit
> 
> b) all initialization (or whatever a user has done to the transport
> layer between calling new() and the next method call) is lost, as
> there's alway a fresh method there.
> 
> This means that users cannot set LWP::UserAgent's characteristica by
> calling $soap->transport->some_lwp_method(1);, because send_receive (at
> least in the HTTP transport class) might call $self->endpoint, and thus
> operate on a new object.
> 
> Are there any reasons for SOAP::Client behaving like this ? If not, I'd
> change the line to 
> 
>  my $self = ref $_[0] ? shift : shift->new();
> 
> which also guarantees there's a valid SOAP::Client object, but does not 
> override existing ones.
> 
> This might induce subtle side effects, even though there's no effect on
> the test suite.
> 
> Any opinions ?
> 
> Marti
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 

Re: [Soaplite-devel] SOAP::Client

[Robert L. <rla...@ao...>]

Paul Kulchenko wrote:
> Martin/Rob,
> 
> As far as I remember, this was to allow someone to create objects
> with:
> 
> CLASS->endpoint(...)
> 
> rather than
> 
> CLASS->new->endpoint(...)
> 
> with both $obj->endpoint(...) and $obj->new->endpoint(...) still
> working as expected.
> 

What follows is opinion, and not a change request.

I've always found CLASS->method to be very confusing to use.  I also 
find object nesting confusing... i.e. 
CLASS->method(args)->other_method()->result.

I think the loose object model actually leads to more confusion rather 
than making the module easier to use, because theres just TOO MANY ways 
to do the same thing.  And when following a standard protocol, in this 
case SOAP, having lots of different interpretations really defeats the 
purpose.

The LWP method of creating multiple objects for your user agent and 
envelope is more along the lines of what I would expect with a SOAP 
implementation.  This would also allow for error checking at different 
levels of the transport, something I've never quite managed to get right 
with SOAP lite.

Rob

Re: [Soaplite-devel] SOAP::Client

[Paul K. <pau...@ya...>]

Martin/Rob,

As far as I remember, this was to allow someone to create objects
with:

CLASS->endpoint(...)

rather than

CLASS->new->endpoint(...)

with both $obj->endpoint(...) and $obj->new->endpoint(...) still
working as expected.

We should probably have something in the tests to cover this. I
remember this technique being used in examples. Probably went too far
in my quest for simplification.

> > calling $soap->transport->some_lwp_method(1);, because
> send_receive (at
> > least in the HTTP transport class) might call $self->endpoint,
> and thus
> > operate on a new object.

As Rob mentioned, this should still work as a new object is only
created for a CLASS call.

Paul.

--- Robert Landrum <rla...@ao...> wrote:

> Martin Kutter wrote:
> > 
> > b) all initialization (or whatever a user has done to the
> transport
> > layer between calling new() and the next method call) is lost, as
> > there's alway a fresh method there.
> > 
> > This means that users cannot set LWP::UserAgent's characteristica
> by
> > calling $soap->transport->some_lwp_method(1);, because
> send_receive (at
> > least in the HTTP transport class) might call $self->endpoint,
> and thus
> > operate on a new object.
> 
> I noticed this too...  But I tracked the new method back and it
> appears 
> to actually do the right thing...  Depending on the inheritance of 
> SOAP::Client, that is...
> 
> In other words, almost all the $obj->new methods in Lite.pm do the 
> following...
> 
> sub new {
>    my $self = shift;
>    return $self if ref $self;
>    ...
> }
> 
> So the new method isn't really creating new objects, which is
> definitely 
> confusing...  :)
> 
> Rob
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

Re: [Soaplite-devel] SOAP::Client

[Robert L. <rla...@ao...>]

Martin Kutter wrote:
> 
> b) all initialization (or whatever a user has done to the transport
> layer between calling new() and the next method call) is lost, as
> there's alway a fresh method there.
> 
> This means that users cannot set LWP::UserAgent's characteristica by
> calling $soap->transport->some_lwp_method(1);, because send_receive (at
> least in the HTTP transport class) might call $self->endpoint, and thus
> operate on a new object.

I noticed this too...  But I tracked the new method back and it appears 
to actually do the right thing...  Depending on the inheritance of 
SOAP::Client, that is...

In other words, almost all the $obj->new methods in Lite.pm do the 
following...

sub new {
   my $self = shift;
   return $self if ref $self;
   ...
}

So the new method isn't really creating new objects, which is definitely 
confusing...  :)

Rob

Re: [Soaplite-devel] SOAP::Client

[Scott W. <sc...@pe...>]

On Thu, Oct 04, 2007 at 12:44:06PM +0200, Martin Kutter wrote:
> Hi there,
> 
> around line 2250 in SOAP/Lite.pm, there's the package SOAP::Client.
> 
> 
> Are there any reasons for SOAP::Client behaving like this ? If not, I'd
> change the line to 
> 
>  my $self = ref $_[0] ? shift : shift->new();

I don't use S::C, but I agree with your assessment and solution.
> 
> This might induce subtle side effects, even though there's no effect on
> the test suite.

Without a test, the user hasn't ever had a guarantee. Perhaps you can
make a test that would trigger a fault as the code exists now, you
implement your fix, and push out a few provisional releases so some
S::C users could try it out for you.

Scott
-- 
Scott Wiersdorf
<sc...@pe...>

[Soaplite-devel] SOAP::Client

[Martin K. <mar...@fe...>]

Hi there,

around line 2250 in SOAP/Lite.pm, there's the package SOAP::Client.

It creates a bunch of setter/getter methods, like this:

 *$method = sub {
   my $self = shift->new;
   @_ 
	? ($self->{$field} = shift, return $self) 
	: return $self->{$field};
 }

I stumbled across the first line of these methods today, when writing a
loopback test transport backend: It calls the transport backend's new() 
every time one of these methods is called, regardless of whether it's
been called before.n

In my opinion, this introduces two misbehaviours:

a) the constructor new() is frequently called as an object method -
which is a perlish, but nonetheless bad habit

b) all initialization (or whatever a user has done to the transport
layer between calling new() and the next method call) is lost, as
there's alway a fresh method there.

This means that users cannot set LWP::UserAgent's characteristica by
calling $soap->transport->some_lwp_method(1);, because send_receive (at
least in the HTTP transport class) might call $self->endpoint, and thus
operate on a new object.

Are there any reasons for SOAP::Client behaving like this ? If not, I'd
change the line to 

 my $self = ref $_[0] ? shift : shift->new();

which also guarantees there's a valid SOAP::Client object, but does not 
override existing ones.

This might induce subtle side effects, even though there's no effect on
the test suite.

Any opinions ?

Marti

[Soaplite-devel] SOAP::Lite maintenance

[Martin K. <mar...@fe...>]

Hi all there,

after a quick look through the open items on Sourceforge & CPAN, I've
decided that one of my first steps will be working through the mass of
items.

I won't address all of the items tracker right now, but priorize them,
and start with the ones including patches (I like it when someone else
has already done the hard work).

In parallel, I'm going to improve SOAP::Lite's test suite - a run with
Devel::Cover shows a a coverage of 55% (report at the end). I always
fear I break things, unless there's tests to prove I don't.

I believe in "release early, release often", so I'm going to wrap up
things for a release around every month - but don't fear, I'll be using
CPAN's pre-release mechanism so the main releases will stay stable (and
occur less often).

Watch out for updates,

Martin

------------------------------------ ------ ------ ------ ------ ------
File                                  stmt   bran   cond    sub  total
------------------------------------ ------ ------ ------ ------ ------
blib/lib/Apache/SOAP.pm                81.8    n/a    n/a   75.0   80.0
blib/lib/Apache/XMLRPC/Lite.pm         81.8    n/a    n/a   75.0   80.0
blib/lib/IO/SessionData.pm             25.0    4.8    0.0   28.6   19.6
blib/lib/IO/SessionSet.pm              26.2    0.0    0.0   43.8   19.7
blib/lib/SOAP/Lite.pm                  77.0   61.7   51.6   82.9   69.3
blib/lib/SOAP/Packager.pm              53.2   32.3   52.6   67.6   50.8
blib/lib/SOAP/Test.pm                  11.8    5.0    1.8   46.7   10.8
blib/lib/SOAP/Transport/FTP.pm         34.0    0.0    0.0   75.0   25.3
blib/lib/SOAP/Transport/HTTP.pm        41.3   24.4   14.3   49.1   32.2
blib/lib/SOAP/Transport/IO.pm          60.8    0.0    0.0   76.9   48.2
blib/lib/SOAP/Transport/JABBER.pm      77.8    n/a    n/a  100.0   83.3
blib/lib/SOAP/Transport/LOCAL.pm       32.1    0.0    0.0   60.0   28.6
blib/lib/SOAP/Transport/MAILTO.pm      28.8    0.0    0.0   62.5   23.0
blib/lib/SOAP/Transport/MQ.pm          77.8    n/a    n/a  100.0   83.3
blib/lib/SOAP/Transport/POP3.pm        48.0    0.0    0.0   57.1   34.0
blib/lib/SOAP/Transport/TCP.pm         54.5   19.6   19.4   61.5   42.5
blib/lib/UDDI/Lite.pm                  53.0    9.3    8.3   65.1   38.0
blib/lib/XML/Parser/Lite.pm            97.5   95.5   75.0   88.2   94.4
blib/lib/XMLRPC/Lite.pm                83.3   65.2   33.3   85.4   77.4
blib/lib/XMLRPC/Test.pm                27.6   11.1    8.3   58.3   26.4
blib/lib/XMLRPC/Transport/HTTP.pm      75.0    n/a    n/a   66.7   72.7
blib/lib/XMLRPC/Transport/POP3.pm     100.0    n/a    n/a  100.0  100.0
blib/lib/XMLRPC/Transport/TCP.pm      100.0    n/a    n/a  100.0  100.0
Total                                  62.1   46.2   36.9   73.3   55.7
------------------------------------ ------ ------ ------ ------ ------

Re: [Soaplite-devel] SOAP::Lite maintenance

[Martin K. <mar...@fe...>]

Hi there,

thank you all vor your votes (whether needed or not).

What's needed next, I guess, is Byrnes vote - if he wants to. 

Thanks again for all the foreward praises.

Martin


Am Donnerstag, den 27.09.2007, 09:13 -0700 schrieb Paul Kulchenko:
> Martin,
> 
> You have my vote too. I also support high praise for all the work
> that Byrne has done on the package. I do agree that a change is
> needed. Byrne and I have discussed this several times in the past as
> none of us has time to continue doing this on a regular basis and we
> haven't had any volunteers to take on active maintenance. I can
> assist you with collecting bug reports, fixes and patches as some of
> them have been submitted directly to Byrne and me. I can also answer
> your design questions (if you have any).
> 
> Paul.
> 
> --- Peter Conrey <pfc...@ho...> wrote:
> 
> > You've got my vote as well
> > 
> > 
> > > From: Scott Wiersdorf <sc...@pe...>
> > > Date: Thu, 27 Sep 2007 09:31:42 -0600
> > > To: <soa...@li...>
> > > Cc: <by...@ma...>
> > > Subject: Re: [Soaplite-devel] SOAP::Lite maintenance
> > > 
> > > On Thu, Sep 27, 2007 at 02:15:20PM +0000, Martin Kutter wrote:
> > > 
> > >> I hereby offer to take over maintenance of the SOAP::Lite
> > module.
> > > 
> > > +1
> > > 
> > > I know Byrne's been swamped and has asked for help in the past.
> > You've
> > > got my vote (if it's needed). We should also praise Byrne for all
> > the
> > > good work he's done on SOAP::Lite. All of us using it now owe a
> > great
> > > deal to him. Thanks Byrne, and welcome Martin!
> > > 
> > > Scott
> > > -- 
> > > Scott Wiersdorf
> > > <sc...@pe...>
> > > 
> > >
> 
> 
> 
> 
>        
> ____________________________________________________________________________________
> Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
> http://answers.yahoo.com/dir/?link=list&sid=396545433
> 

Re: [Soaplite-devel] SOAP::Lite maintenance

[David B. <Dav...@qm...>]

+5 to Martin.  :-)
an extra +5 when I see patches!  :-)

+10 to Byrne if you give him the acccess he requires.   (like passing PAU=
SE primary maintainer status to martin, or at least giving martin co-main=
tainer status).

Buzz.

-----Original Message-----
From: soa...@li...
[mailto:soa...@li...]On Behalf Of Martin
Kutter
Sent: Friday, 28 September 2007 12:15 AM
To: by...@ma...
Cc: soa...@li...
Subject: [Soaplite-devel] SOAP::Lite maintenance


Hi Byrne,

as far as I can see, SOAP::Lite is currently not being maintained.=20

In my opinion, this is a quite undesirable state, as SOAP and XMLRPC appl=
ications
become more and more widespread, and other languages like python already =
provide
support for them in there standard library.

I hereby offer to take over maintenance of the SOAP::Lite module.

My plans for SOAP::Lite maintenance are:

1) Work down the list of bug reports on CPAN & sourceforge
2) Split the SOAP/Lite.pm into separate files, while completely preservin=
g SOAP::Lite's
API
   In my opinion, the BIG SOAP/Lite.pm is one of the most serious design=20
   flaws in SOAP::Lite. This can easily be changed by moving to a=20
   one package/one file stragey.
   Separating packages into different files eases maintenance, and makes=20
   SOAP::Lite more "lightweight"
3) Factor out the seldomly used parts into separate packages.
   In my opinion, there's no need for Jabber or MQ support in SOAP-Lite -=
=20
   they could easily be factored out into SOAP-Lite-Jabber and SOAP-Lite-=
MQ

   distributions.
   I bet there's more to come...
4) Centralize contact.
   - move the yahoo groups user support forum to a user mailing list=20
     on sourceforge
   - move soaplite.com to soap-lite.sourceforge.net

To introduce myself: I'm known on CPAN as MKUTTER. I'm the author of SOAP=
::WSDL,
a WSDL-based frontend for SOAP::Lite. I'm currently doing a complete rewr=
ite
of SOAP::WSDL, and have learned - the hard way - that I can't use too muc=
h of
SOAP::Lite as a base for SOAP::WSDL - actually, the only usable part is t=
he
transport backends.

I'm also receiving user comments suggesting improvements which cannot be =
done
without modifying SOAP::Lite, too.

I consider this a very bad situation, which could be fixed easily - provi=
ded
SOAP::Lite would be actively maintained.=20

As there seems no one there to do the task, I'd just offer to do it mysel=
f.


Regards,

Martin
* Gesendet mit / Sent by: FEN-Webmail * http://www.fen-net.de *

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Soaplite-devel mailing list
Soa...@li...
https://lists.sourceforge.net/lists/listinfo/soaplite-devel


The message and any attachment is confidential and may be privileged or o=
therwise protected from disclosure. If you have received it by mistake pl=
ease let us know by reply and then delete it from your system; you should=
 not copy the message or disclose its contents to anyone.

Re: [Soaplite-devel] SOAP::Lite maintenance

[rahed <ra...@gm...>]

On Thu, 27 Sep 2007 14:15:20 00200, Martin Kutter
<mar...@fe...> wrote:

> I hereby offer to take over maintenance of the SOAP::Lite module.

I second your decision and also am lots grateful to those who have
maintained this module.

-- 
Radek

Re: [Soaplite-devel] SOAP::Lite maintenance

[Alasdair A. <aa...@as...>]

Martin Kutter wrote:
> I hereby offer to take over maintenance of the SOAP::Lite module.

The cavalry has arrived? You've got my vote...

Bryne has put a lot of work into the module, but it's a module that  
needs heavy and active maintenance, and meaning absolutely no  
criticism to Bryne, I don't think it's getting it right now.

Al.

Re: [Soaplite-devel] SOAP::Lite maintenance

[Scott W. <sc...@pe...>]

On Thu, Sep 27, 2007 at 09:13:12AM -0700, Paul Kulchenko wrote:
> Martin,
> 
> You have my vote too. I also support high praise for all the work
> that Byrne has done on the package.

Paul! Why did I neglect Paul? My bad.

We owe Paul great praise for writing S::L in the first place!

Martin will be joining a praiseworthy group of developers and S::L
maintainers.

Scott
-- 
Scott Wiersdorf
<sc...@pe...>

Re: [Soaplite-devel] SOAP::Lite maintenance

[<Kev...@us...>]

Ditto, good luck and thanks. :)






Scott Wiersdorf <sc...@pe...> 
Sent by: soa...@li...
09/27/2007 10:31 AM

To
soa...@li...
cc
by...@ma...
Subject
Re: [Soaplite-devel] SOAP::Lite maintenance






On Thu, Sep 27, 2007 at 02:15:20PM +0000, Martin Kutter wrote:

> I hereby offer to take over maintenance of the SOAP::Lite module.

+1

I know Byrne's been swamped and has asked for help in the past. You've
got my vote (if it's needed). We should also praise Byrne for all the
good work he's done on SOAP::Lite. All of us using it now owe a great
deal to him. Thanks Byrne, and welcome Martin!

Scott
-- 
Scott Wiersdorf
<sc...@pe...>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Soaplite-devel mailing list
Soa...@li...
https://lists.sourceforge.net/lists/listinfo/soaplite-devel



-  For more information about UL, its Marks, and its services for
EMC, quality registrations and product certifications for global
markets, please access our web sites at http://www.ul.com and
http://www.ulc.ca or contact your local sales representative. --

********* Internet E-mail Confidentiality Disclaimer **********
This e-mail message may contain privileged or confidential
information. If you are not the intended recipient, you may not
disclose, use, disseminate, distribute, copy or rely upon this
message or attachment in any way. If you received this e-mail
message in error, please return by forwarding the message and
its attachments to the sender.

UL and its affiliates do not accept liability for any errors,
omissions, corruption or virus in the contents of this message
or any attachments.
*****************************************************************

Re: [Soaplite-devel] SOAP::Lite maintenance

[Paul K. <pau...@ya...>]

Martin,

You have my vote too. I also support high praise for all the work
that Byrne has done on the package. I do agree that a change is
needed. Byrne and I have discussed this several times in the past as
none of us has time to continue doing this on a regular basis and we
haven't had any volunteers to take on active maintenance. I can
assist you with collecting bug reports, fixes and patches as some of
them have been submitted directly to Byrne and me. I can also answer
your design questions (if you have any).

Paul.

--- Peter Conrey <pfc...@ho...> wrote:

> You've got my vote as well
> 
> 
> > From: Scott Wiersdorf <sc...@pe...>
> > Date: Thu, 27 Sep 2007 09:31:42 -0600
> > To: <soa...@li...>
> > Cc: <by...@ma...>
> > Subject: Re: [Soaplite-devel] SOAP::Lite maintenance
> > 
> > On Thu, Sep 27, 2007 at 02:15:20PM +0000, Martin Kutter wrote:
> > 
> >> I hereby offer to take over maintenance of the SOAP::Lite
> module.
> > 
> > +1
> > 
> > I know Byrne's been swamped and has asked for help in the past.
> You've
> > got my vote (if it's needed). We should also praise Byrne for all
> the
> > good work he's done on SOAP::Lite. All of us using it now owe a
> great
> > deal to him. Thanks Byrne, and welcome Martin!
> > 
> > Scott
> > -- 
> > Scott Wiersdorf
> > <sc...@pe...>
> > 
> >




       
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. 
http://answers.yahoo.com/dir/?link=list&sid=396545433

Re: [Soaplite-devel] SOAP::Lite maintenance

[Matthew R. <mr...@za...>]

Good luck! SOAP::Lite is a scary place =p

There was some talk of a reworking of SOAP::Lite in the past, but I'm  
not sure what came of it.

+--------------------------------------------------------+
  | Matthew Runo
  | Zappos Development
  | mr...@za...
  | 702-943-7833
+--------------------------------------------------------+


On Sep 27, 2007, at 5:15 AM, Martin Kutter wrote:

> Hi Byrne,
>
> as far as I can see, SOAP::Lite is currently not being maintained.
>
> In my opinion, this is a quite undesirable state, as SOAP and  
> XMLRPC applications
> become more and more widespread, and other languages like python  
> already provide
> support for them in there standard library.
>
> I hereby offer to take over maintenance of the SOAP::Lite module.
>
> My plans for SOAP::Lite maintenance are:
>
> 1) Work down the list of bug reports on CPAN & sourceforge
> 2) Split the SOAP/Lite.pm into separate files, while completely  
> preserving SOAP::Lite's
> API
>    In my opinion, the BIG SOAP/Lite.pm is one of the most serious  
> design
>    flaws in SOAP::Lite. This can easily be changed by moving to a
>    one package/one file stragey.
>    Separating packages into different files eases maintenance, and  
> makes
>    SOAP::Lite more "lightweight"
> 3) Factor out the seldomly used parts into separate packages.
>    In my opinion, there's no need for Jabber or MQ support in SOAP- 
> Lite -
>    they could easily be factored out into SOAP-Lite-Jabber and SOAP- 
> Lite-MQ
>
>    distributions.
>    I bet there's more to come...
> 4) Centralize contact.
>    - move the yahoo groups user support forum to a user mailing list
>      on sourceforge
>    - move soaplite.com to soap-lite.sourceforge.net
>
> To introduce myself: I'm known on CPAN as MKUTTER. I'm the author  
> of SOAP::WSDL,
> a WSDL-based frontend for SOAP::Lite. I'm currently doing a  
> complete rewrite
> of SOAP::WSDL, and have learned - the hard way - that I can't use  
> too much of
> SOAP::Lite as a base for SOAP::WSDL - actually, the only usable  
> part is the
> transport backends.
>
> I'm also receiving user comments suggesting improvements which  
> cannot be done
> without modifying SOAP::Lite, too.
>
> I consider this a very bad situation, which could be fixed easily -  
> provided
> SOAP::Lite would be actively maintained.
>
> As there seems no one there to do the task, I'd just offer to do it  
> myself.
>
>
> Regards,
>
> Martin
> * Gesendet mit / Sent by: FEN-Webmail * http://www.fen-net.de *
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>

Re: [Soaplite-devel] SOAP::Lite maintenance

[Peter C. <pfc...@ho...>]

You've got my vote as well


> From: Scott Wiersdorf <sc...@pe...>
> Date: Thu, 27 Sep 2007 09:31:42 -0600
> To: <soa...@li...>
> Cc: <by...@ma...>
> Subject: Re: [Soaplite-devel] SOAP::Lite maintenance
> 
> On Thu, Sep 27, 2007 at 02:15:20PM +0000, Martin Kutter wrote:
> 
>> I hereby offer to take over maintenance of the SOAP::Lite module.
> 
> +1
> 
> I know Byrne's been swamped and has asked for help in the past. You've
> got my vote (if it's needed). We should also praise Byrne for all the
> good work he's done on SOAP::Lite. All of us using it now owe a great
> deal to him. Thanks Byrne, and welcome Martin!
> 
> Scott
> -- 
> Scott Wiersdorf
> <sc...@pe...>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>