soaplite-devel

[Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Hi Robbie,

I've just had my first run on the split up SOAP::Lite you did. After
some adjustments, the test suite passed again.

I started moving most modules from the SOAP:: namespace into
SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
namespace), so SOAP::Lite won't get indexed on CPAN when containing
conflicting packages.
(theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).

There's a few packages I don't like to be moved in the first run:

SOAP::Data and SOAP::Header: Both are so widely used that moving them
would break almost every SOAP client/server

SOAP::Transport::*: The transport layer is sometimes used from other
distributions.

I'd suggest providing these modules twice - as SOAP:: and SOAP::Lite::
variant in the next release, and marking them as deprecated. This way
users have a chance to catch up...

Martin

Re: [Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Ah, I forgot to mention that I have not deleted the modules moved into
the SOAP/Lite/ hierarchy, so for now they are there in two places.

Martin

Re: [Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Am Sonntag, den 02.03.2008, 09:46 +0000 schrieb Robbie Bow:
> On Sun, Mar 2, 2008 at 8:19 AM, Martin Kutter <mar...@fe...> wrote:
> > Ah, I forgot to mention that I have not deleted the modules moved into
> >  the SOAP/Lite/ hierarchy, so for now they are there in two places.
> >
> 
> Will that be the case for release or is it a temporary state of affairs?

I don't know yet - I guess we'll have to deside that before the next
release. Could make sense to keep some to still allow subclassing - like
SOAP::Serializer - but I think most can be deleted.

Martin

Re: [Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Martin/Robbie,

I was aware of the SOAP:: namespace when the module was created and I
was careful not to overlap with the modules that were in the SOAP
namespace. It was possible to use both SOAP::Lite and SOAP modules in
the same application for some time. However, after several years I
stopped paying attention to this as the SOAP module didn't seem to be
supported at all and didn't seem to be used much.

Would it be easier to resolve namespace conflicts in favor of
SOAP::Lite given the current state of the SOAP module instead of
migrating/renaming everything under SOAP::Lite namespace? We can ask
Keith Brown, the author of the SOAP.pm module, if he is okay with
transferring the namespace. The (original) idea was that the main
module is under S::L namespace, while others, like ::Transport and
::Data will be under SOAP:: namespace to avoid too many levels in the
hierarchy. Probably not the best way, but it seemed to be the most
straightforward at the time. Even now, I don't like the idea of
having everything under S::L namespace.

Paul.

--- Martin Kutter <mar...@fe...> wrote:

> Hi Robbie,
> 
> I've just had my first run on the split up SOAP::Lite you did.
> After
> some adjustments, the test suite passed again.
> 
> I started moving most modules from the SOAP:: namespace into
> SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
> namespace), so SOAP::Lite won't get indexed on CPAN when containing
> conflicting packages.
> (theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).
> 
> There's a few packages I don't like to be moved in the first run:
> 
> SOAP::Data and SOAP::Header: Both are so widely used that moving
> them
> would break almost every SOAP client/server
> 
> SOAP::Transport::*: The transport layer is sometimes used from
> other
> distributions.
> 
> I'd suggest providing these modules twice - as SOAP:: and
> SOAP::Lite::
> variant in the next release, and marking them as deprecated. This
> way
> users have a chance to catch up...
> 
> Martin
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

Re: [Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

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

Hi Paul,

This has not been so much a problem when all packages were in Lite.pm -
now, as we're separating packages for maintainability, it is.

SOAP is still being used - so I'd prefer to resolve the existing
conflicts on SOAP::Lite's side.

The overlapping names are

 SOAP::Serializer
 SOAP::Packager
 SOAP::Transport::HTTP::CGI
 SOAP::Transport::HTTP::Client
 SOAP::Transport::HTTP::Server

We could move those and leave the rest - it's a bit inconsistent, but
actually I don't care, except for those conflicts.

Martin

Am Sonntag, den 02.03.2008, 09:51 -0800 schrieb Paul Kulchenko:
> Martin/Robbie,
> 
> I was aware of the SOAP:: namespace when the module was created and I
> was careful not to overlap with the modules that were in the SOAP
> namespace. It was possible to use both SOAP::Lite and SOAP modules in
> the same application for some time. However, after several years I
> stopped paying attention to this as the SOAP module didn't seem to be
> supported at all and didn't seem to be used much.
> 
> Would it be easier to resolve namespace conflicts in favor of
> SOAP::Lite given the current state of the SOAP module instead of
> migrating/renaming everything under SOAP::Lite namespace? We can ask
> Keith Brown, the author of the SOAP.pm module, if he is okay with
> transferring the namespace. The (original) idea was that the main
> module is under S::L namespace, while others, like ::Transport and
> ::Data will be under SOAP:: namespace to avoid too many levels in the
> hierarchy. Probably not the best way, but it seemed to be the most
> straightforward at the time. Even now, I don't like the idea of
> having everything under S::L namespace.
> 
> Paul.
> 
> --- Martin Kutter <mar...@fe...> wrote:
> 
> > Hi Robbie,
> > 
> > I've just had my first run on the split up SOAP::Lite you did.
> > After
> > some adjustments, the test suite passed again.
> > 
> > I started moving most modules from the SOAP:: namespace into
> > SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
> > namespace), so SOAP::Lite won't get indexed on CPAN when containing
> > conflicting packages.
> > (theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).
> > 
> > There's a few packages I don't like to be moved in the first run:
> > 
> > SOAP::Data and SOAP::Header: Both are so widely used that moving
> > them
> > would break almost every SOAP client/server
> > 
> > SOAP::Transport::*: The transport layer is sometimes used from
> > other
> > distributions.
> > 
> > I'd suggest providing these modules twice - as SOAP:: and
> > SOAP::Lite::
> > variant in the next release, and marking them as deprecated. This
> > way
> > users have a chance to catch up...
> > 
> > Martin
> > 
> > 
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Soaplite-devel mailing list
> > Soa...@li...
> > https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> > 
> 
> 
> 
>       ____________________________________________________________________________________
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 
> 

Re: [Soaplite-devel] SOAP::Lite refactoring - splitting up SOAP::Lite

[Robbie B. <rob...@gm...>]

I think consistency has the benefit of making development easier for
developers that contribute in the future. Not a major concern but it
can significantly increase productivity in my experience.

On Sun, Mar 2, 2008 at 6:31 PM, Martin Kutter <mar...@fe...> wrote:
> Hi Paul,
>
>  This has not been so much a problem when all packages were in Lite.pm -
>  now, as we're separating packages for maintainability, it is.
>
>  SOAP is still being used - so I'd prefer to resolve the existing
>  conflicts on SOAP::Lite's side.
>
>  The overlapping names are
>
>   SOAP::Serializer
>   SOAP::Packager
>   SOAP::Transport::HTTP::CGI
>   SOAP::Transport::HTTP::Client
>   SOAP::Transport::HTTP::Server
>
>  We could move those and leave the rest - it's a bit inconsistent, but
>  actually I don't care, except for those conflicts.
>
>  Martin
>
>  Am Sonntag, den 02.03.2008, 09:51 -0800 schrieb Paul Kulchenko:
>
>
> > Martin/Robbie,
>  >
>  > I was aware of the SOAP:: namespace when the module was created and I
>  > was careful not to overlap with the modules that were in the SOAP
>  > namespace. It was possible to use both SOAP::Lite and SOAP modules in
>  > the same application for some time. However, after several years I
>  > stopped paying attention to this as the SOAP module didn't seem to be
>  > supported at all and didn't seem to be used much.
>  >
>  > Would it be easier to resolve namespace conflicts in favor of
>  > SOAP::Lite given the current state of the SOAP module instead of
>  > migrating/renaming everything under SOAP::Lite namespace? We can ask
>  > Keith Brown, the author of the SOAP.pm module, if he is okay with
>  > transferring the namespace. The (original) idea was that the main
>  > module is under S::L namespace, while others, like ::Transport and
>  > ::Data will be under SOAP:: namespace to avoid too many levels in the
>  > hierarchy. Probably not the best way, but it seemed to be the most
>  > straightforward at the time. Even now, I don't like the idea of
>  > having everything under S::L namespace.
>  >
>  > Paul.
>  >
>  > --- Martin Kutter <mar...@fe...> wrote:
>  >
>  > > Hi Robbie,
>  > >
>  > > I've just had my first run on the split up SOAP::Lite you did.
>  > > After
>  > > some adjustments, the test suite passed again.
>  > >
>  > > I started moving most modules from the SOAP:: namespace into
>  > > SOAP::Lite:: - SOAP is another CPAN distribution (which owns the
>  > > namespace), so SOAP::Lite won't get indexed on CPAN when containing
>  > > conflicting packages.
>  > > (theres 2 tickets open for SOAP::Lite namespace issues on CPAN RT).
>  > >
>  > > There's a few packages I don't like to be moved in the first run:
>  > >
>  > > SOAP::Data and SOAP::Header: Both are so widely used that moving
>  > > them
>  > > would break almost every SOAP client/server
>  > >
>  > > SOAP::Transport::*: The transport layer is sometimes used from
>  > > other
>  > > distributions.
>  > >
>  > > I'd suggest providing these modules twice - as SOAP:: and
>  > > SOAP::Lite::
>  > > variant in the next release, and marking them as deprecated. This
>  > > way
>  > > users have a chance to catch up...
>  > >
>  > > Martin
>  > >
>  > >
>  > >
>  > -------------------------------------------------------------------------
>  > > This SF.net email is sponsored by: Microsoft
>  > > Defy all challenges. Microsoft(R) Visual Studio 2008.
>  > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  > > _______________________________________________
>  > > Soaplite-devel mailing list
>  > > Soa...@li...
>  > > https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>  > >
>  >
>  >
>  >
>  >       ____________________________________________________________________________________
>  > Be a better friend, newshound, and
>  > know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>  >
>
>