Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

an email

here

More on Python

Also by KM

Python to bake-in XML-RPC support

posted by KM on 2001.07.12 7:32   Printer-friendly
Python
Randy Ray sent an email to p5p regarding Python baking in XML-RPC support. Randy says in the email "If 5.8 were to have LWP and XML support native, I could ensure that my RPC::XML package would work, to accomplish the same thing for Perl." You can see the original email sent to the XML-RPC list by David Winer, here where he makes the disturbing statement, "As often is the case Python leads the way."

What do you think? Does Perl need XML-RPC bundled into the core? Why or why not?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Python to bake-in XML-RPC support 24 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I'm personally reluctant to see core bloat. On the other hand, I think all languages are really heading this way, and Perl probably needs to do this "to keep up." And, I've actually liked every decision to include new modules with Perl made in the last three or four years, and I don't think it would be the end of the world for this one.

    I presume from the statements made in the post that XML::RPC is mature and robust enough to include. (Haven't used it myself.)

    Wouldn't it be nice to see several standa

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • mod_perl running XML stuff often chokes because of the incompatible expat-lite that is compiled into apache. Perhaps the correct answer here is to rewrite apache to use the "standard" expat, but I could see where this will become a more common problem if XML were officially incorporated into the perl base.
  • Web Services are *very* new. Although I'm a big fan of XML-RPC, I don't know how you would include
    XML-RPC (and *which* XML-RPC module? There are three) without including the buzz-fest that is SOAP. Do we roll in everything?

    For me, CPAN is easy to use. It's easy to grab missing modules.
  • Let me just insert here that the RPC::XML code is still under heavy development, but the majority of that is focused on enriching the test suites and documentation. I'm also not 100% sure we should include this, but since people are comparing us (both the specific "us" with reference to the language, and the generic "us" with reference to the community) Python with greater frequency, I wanted to bring the issue up to discussion.

    My personal feeling is that we would benefit from looking at the overall weigh

    --

    --rjray

  • Personally, I would like to see the various distributions. This way I could install, say, perl-web-x.x.x on my webservers, and perl-plain-x.x.x on my other boxes (or perl-net-x.x.x, perl-xml-x.x.x, etc..).

    I'm not convinced we need to add anything into the core simply because Python does. Just because others do, doesn't mean it is a Good Thing. I use Randys RPC::XML modules, and am quite happy with them. If they are in the core, makes my life a bit easier so I don't have to install all the dependencies all

  • This is not what Perl needs. I believe that what is needed is a stable core (or run-time) and a simple way to bundle applications inside a package class (maybe a .pp file?) that contains all the extra modules (.pm) and its associated autoloadable shared libraries. Like a .jar file
    if you may.

    Yes, the package many be architecture dependant but the tool that generates it could quickly build a package from the original application sources.

    In this way deploying an application in another machine can be done
    --
    I can't believe it's anything but Perl!
  • php has been shipping bundled xml-rpc support since last august.
  • We're not talking about putting the expat-based XML::Parser module into the core. We're talking about putting a pure Perl XML parser into the core, and probably a module to do XML-RPC as well.

    So mod_perl would not suffer. And yes, I hate that Apache screws you with its own XML parser mods.

    --Nat

  • SOAP is still a moving target (cf the recent announcement that 1.2 is a microstep closer to being realized). XML-RPC is, at least, stable.

    Which XML-RPC module is simply a decision to be made, not a showstopper.

    --Nat

  • SOAP 1.1 is the most commonly used version of SOAP in use today, and that's fairly stable. Many of the different implementations at this point interoperate well together.


    Pointing to the this week's release of the SOAP 1.2 discussion is like saying "Perl isn't ready for prime time, because Perl6 is just around the corner."

  • But I also know that whenever I install or upgrade on a new machine, the first thing I do is pull the same basic 25-30 modules from CPAN.

    If that's the case, I recommend writing your own local Bundle module with a list of things to install and then using the CPAN module. I tried this once a long time ago and it seemed to work well, but I don't remember all the specifics.

    Of course, you do get bit by some of the modules that require interactive configuration.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • Yes, include all common and useful things in perl distribution. The default really matters. Include LWP in the default distibution, include an XML parser in the default distribution, include DBI and most popular DBD functionality. Ask users what they use most commonly and include it. No, it really doesn't work to tell anybody that you can get it from CPAN. IF there is no builtin XML support, people simply think that perl doesn't have XML support. If perl doesn't come with Mailtools by default, perl doesn't

  • Many sysadmins don't need or want XML with their perl installation. It is not a convincing enough argument to say that most people can't find the extended functionality on CPAN therefore it must be included in the core. Maybe PHP and Python have a different target audience.

    What's wrong with an SDK or bundles to extend functionality to the core?

  • The CPAN search engine stats do not show this module having the minimum of 300 queries to list it which is curious.

  • Let me echo the earlier argument in favor of a broader core. I do a fair amount of programming for clients who have already chosen their web hosting companies. More and more of these web hosting companies no longer give telnet access. As a result, I can only use modules that pure Perl can can be ftp'd up: No Install command for me.

    Consequently, I can't use DBI. (I'm hacking away at Sprite.pm right now). Putting these things into the core would make a big difference.

  • Many sysadmins don't need or want XML with their perl installation.

    By that logic, we should rip out the CGI, Unicode and IO::* bits from Perl because sysadmins neither want nor need them.

    Citing the needs and desires of one particular audience isn't a sufficient argument for or against inclusion of a feature in the standard Perl distribution.
  • Well, citing that Python and PHP include something as a reason to 'get on the bandwagon' isn't a sufficient argument either. The CPAN search engine hasn't had a sufficient number of queries for this module to make it into the statistics that makes me wonder if it is, indeed, all that hot and popular feature.

    And sysadmins, like it or not, are a large portion of the user base and are the ones who have to deal with installing perl much of the time and keeping the pain of installation to a minimum is not a ba
  • Hmmm, this is very similar to the Linux monolithic vs micro kernel debates. Many times it comes down to deciding if it truly is a "core" function or if someone just thinks "geee my stuff would really run better if it was part of the kernel!"

    Note: this is just a general comment on the include in core argument and not about XML::RPC.
  • > We're talking about putting a pure Perl XML parser into the core, and probably a module to do XML-RPC as well.

    btw, speaking about pure Perl XML parser (is there one?), next version of XML::Parser::Lite works on perl 5.005, perl5.6, and 5.7 for me. SOAP::Lite and improved XMLRPC::Lite can use either XML::Parser or XML::Parser::Lite. Lite version doesn't handle char/entity decoding and doesn't have a charset support yet. I can put more efforts into it if there is an interest. Since Lite version implem

  • You may find both SOAP (173) and SOAP::Lite (253) as a search requests in 2001 stats. RPC is also there. SOAP::Lite is bundled with XMLRPC::Lite module, so it may show interest in both of them. SOAP is already 81 in June and 59 in July. http://www.soaplite.com/ is also in top20 referrers. I think it definitely shows the interest.

    Paul.

  • The recent versions of ActiveState's ActivePerl all have Soap::Lite included in the distribution. Soap::Lite is what they use to power their PPM (Perl Package Manager) system. Since the majority of Windows users don't have compilers, ActiveState uses PPM ditribute packages to users. As they update to the newer versions of Soap::Lite, XMLRPC::Lite will also become part of the core for ActiveState (at least for Windows). I, for one, would not see the need for two XML-RPC modules as part of the core. How
  • Good point, but we can't let ActiveState's decision dictate which we choose, if one is to be chosen. Personally, I don't see the fact that ActiveState bundles SOAP::Lite to be relevant at all. The pumpking leads, everyone else follows (except for Larry :-).
  • This is the same issue I run into. It becomes difficult to write "portable" code that can not be used in an environment that the admins will not add even the basic extras to (DBI et al).

    I have always had to get around this by writing modules that provide a level of indirection above even the standard modules to allow for my kludges to be used until the site's owner can afford a real server (or can convinve the boss to move to a real server). I have heard the argument plenty of times.. it is there fault
    --

    Workflow automation - The art of simplifying mundane repetitive tasks with other mundane repetitive tasks.
  • I agree that ActiveState cannot dictate what is part of the core. I guess my main point is that SOAP::Lite is relavant. While it also is not a core module, it has become the unofficial standard package for SOAP developers using Perl. Now, everyone who pulls down SOAP::Lite through CPAN (or downloads and makes the newest version) has XMLRPC::Lite installed.

    My concern is having two competing XML-RPC packages in Perl. Yes, I know Perl is all about TMTOWTDI, but I don't recall many cases in Perl where comp
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.