Loading ...
Sorry, an error occurred while loading the content.

Re: [soaplite] SOAP::Lite architecture

Expand Messages
  • Paul Kulchenko
    Hi, Sam! ... I agree. ... Hardly that much, but I ll do some tests to find exact number. ... There are two different problems. Every module uses at least one
    Message 1 of 9 , Jan 20, 2002
    • 0 Attachment
      Hi, Sam!

      --- Sam Tregar <sam@...> wrote:
      > smaller chunks. I can see that this is more of judgment call than
      > anything else...
      I agree.

      > > we can save about 300 lines for client and server, approx 10%.
      > This could be a significant saving - maybe 1MB or more depending on
      > what's actually in those lines.
      Hardly that much, but I'll do some tests to find exact number.

      > It's definitely more convenient. However, considering that you
      > don't
      > "own" the SOAP:: namespace, it's not very polite to create modules
      > there
      > without registering them. If someone else wants to write a SOAP
      > tracing
      > package they have to know that SOAP::Lite has claimed SOAP::Trace
      > already ,
      > for example. The more popular the SOAP protocol gets the more
      > likely this sort of problem is to occur.
      There are two different problems. Every module uses at least one
      namespace, and SOAP::Lite uses about ten of them. Since most of them
      are packaged in one file, it's not easy to find that namespace is
      already taken. Later is easy to address. POD file for every module
      can be created, so it'll be visible for CPAN searches. In addition to
      that, I would expect that SOAP developer that decides to create
      implementation in Perl will be quite familiar with other
      implementations and won't be taken by a surprise.

      First problem is more difficult. Why HTTP::Daemon namespace was used?
      Why not HTTP::LWP::Daemon or LWP::HTTP::Daemon? There are several
      reasons. What if another HTTP-based daemon will be written (in fact
      we have several. One of them is Net::Daemon? Will it create any
      problem? Maybe yes, maybe no. Was Gisle Aas impolite with taking
      HTTP::Daemon namespace? hardly. How about XML::Parser? Can't imagine
      there will be only one.

      You can't easily create several implementations behind one interface
      (unless this interface is already well established, like XML::SAX).
      It's (IMHO) reasonable to expect that there will be several competing
      implementations and some of them will use "better" namespaces. There
      is no "best practices" on thi topic, but I'd like to know different
      opinions, so next time I'll do it right.

      > I don't understand what you mean by this. I've written modules
      > that use multiple namespaces and are separated into multiple files.
      I just meant that if you have:

      -- Foo.pm
      package Foo;

      package Bar;

      you'll be able to do 'use Foo', but not 'use Bar' without doing
      tricks with %INC.

      Best wishes, Paul.

      __________________________________________________
      Do You Yahoo!?
      Send FREE video emails in Yahoo! Mail!
      http://promo.yahoo.com/videomail/
    • Sam Tregar
      ... I ll stick my neck out - I think this one was a bad choice. It probably should have been XML::Parser::Expat or just XML::Expat. But, hey, it s Larry
      Message 2 of 9 , Jan 20, 2002
      • 0 Attachment
        On Sun, 20 Jan 2002, Paul Kulchenko wrote:

        > How about XML::Parser? Can't imagine there will be only one.

        I'll stick my neck out - I think this one was a bad choice. It probably
        should have been XML::Parser::Expat or just XML::Expat. But, hey, it's
        Larry Wall, who's going to argue? ;)

        > There is no "best practices" on thi topic, but I'd like to know
        > different opinions, so next time I'll do it right.

        I strongly disagree. There is a well documented "best practice" - write
        to modules@... and register your namespaces with them. I suspect
        you could have avoided squatting on SOAP:: if you'd gotten their input
        when you started the module!

        > I just meant that if you have:
        >
        > -- Foo.pm
        > package Foo;
        >
        > package Bar;
        >
        > you'll be able to do 'use Foo', but not 'use Bar' without doing
        > tricks with %INC.

        Ah, right. Yes, this is a small problem but it's not a big deal when you
        consider that users shouldn't usually be loading sub-modules directly.

        -sam
      • Paul Kulchenko
        Hi, Sam! ... Actually that s precisely what I did (you can find my message in the archive). And I carefully checked archives on that and related topics. In
        Message 3 of 9 , Jan 21, 2002
        • 0 Attachment
          Hi, Sam!

          --- Sam Tregar <sam@...> wrote:
          > I strongly disagree. There is a well documented "best practice" -
          > write
          > to modules@... and register your namespaces with them. I
          > suspect
          > you could have avoided squatting on SOAP:: if you'd gotten their
          > input when you started the module!
          Actually that's precisely what I did (you can find my message in the
          archive). And I carefully checked archives on that and related
          topics. In most cases you register MAIN namespace for your module,
          but I never heard about registering internal modules and any
          recommendations as for namespaces they should use.

          Best wishes, Paul.

          __________________________________________________
          Do You Yahoo!?
          Send FREE video emails in Yahoo! Mail!
          http://promo.yahoo.com/videomail/
        • Sam Tregar
          ... What is the point of registering a namespace if you don t register all that you intend to use? As I understand it, the point behind registering namespaces
          Message 4 of 9 , Jan 21, 2002
          • 0 Attachment
            On Mon, 21 Jan 2002, Paul Kulchenko wrote:

            > Actually that's precisely what I did (you can find my message in the
            > archive). And I carefully checked archives on that and related
            > topics. In most cases you register MAIN namespace for your module,
            > but I never heard about registering internal modules and any
            > recommendations as for namespaces they should use.

            What is the point of registering a namespace if you don't register all
            that you intend to use? As I understand it, the point behind registering
            namespaces is so that people will know that you "own" that name. Now,
            most modules can get away with just registering the base name since they
            keep their private modules below their base - i.e. registering Foo::Bar
            and then including Foo::Bar::Baz and Foo::Bar::Bif. However, the same
            does not apply to registering Foo::Bar and then including Foo::Baz and
            Foo::Bif in your distribution.

            But I think you understand what I'm saying - I don't mean to beat you over
            the head with it. What's done is done, right?

            -sam
          Your message has been successfully submitted and would be delivered to recipients shortly.