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?
Probably a good idea
jdavidb on 2001-07-12T17:11:34
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 standard distributions of Perl? perl-plain-5.8.0.tar.gz, perl-web-5.8.0.tar.gz, perl-tk-5.8.0.tar.gz, etc. (Perl-CPAN-total-5.8.0.tar.gz? Nah!)
mod_perl might suffer
cjb on 2001-07-12T19:57:24
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.
Not SOAP too?
jjohn on 2001-07-12T20:05:34
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.
Re:Probably a good idea
rjray on 2001-07-12T20:14:02
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 weight of the Python distribution before couching any of the arguments in issues of distribution bloat. And the idea of having companion chunks a la perl-lib.X.XX.tar.gz is worth consideration. Certainly CPAN is easy to use and more than adequate (why, I even use it myself :-). 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.
Randy
Re:Probably a good idea
KM on 2001-07-12T20:38:29
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 the time :) Maybe a better thing would be to just get XML parsing support in the core, then let people who want RPC or SOAP install what they need from CPAN.
I don't use Python, so I don't know if they have a facility like CPAN.
Re:Probably a good idea
sergio on 2001-07-12T20:58:33
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 simply and conveniently in places where only the basic runtime is available. If you want to use XML-* then you can download the packages you like from CPAN, build the app, test and then deploy (withtin the same architecture).
If domething else is hot next year... then it can be bundled quickly.
You see it is not the availability of the modules
in the basic distribution the problem but how to
make sure there is a consistent set of packages
in your current Perl installation to allow your
app to run. With a minimal run time and the packager then this can be an non-issue!
python wasn't much of a leader.
jimw on 2001-07-12T21:01:07
php has been shipping bundled xml-rpc support since last august.
Re:mod_perl might suffer
gnat on 2001-07-12T21:38:26
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
Re:Not SOAP too?
gnat on 2001-07-12T21:52:14
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
Re:Not SOAP too?
ziggy on 2001-07-12T22:54:47
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."
Re:Probably a good idea
jdavidb on 2001-07-13T02:12:09
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.
My opinion and experience
solhell on 2001-07-13T10:09:33
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 support email, etc.
What happens is that majority of the users are located on virtual hosting servers. Each server probably host 400-500 domains/users. Well lets consider CGI users for a second. I am pretty sure these correspond to a big percentage. The admin usually installs (compiles) the default perl and that is it. They don't want to touch it just in case if it breaks something else.
There are countless software companies who gave up using LWP in their products after getting responses from 20-50% of the users that think that the software doesn't work. Most of them doesn't even bother and contact their credit card companies for refund. Strangely enough, when these users ask their system admin to install LWP, most of the time the response is that "what is LWP?". One would expect that a system admin is highly familiar with perl.
These are one of the main resons that Php got popular among CGI/web software developpers. It just comes with bunch of basic functionality by default (even though perl has more powerful tools for these in CPAN). When you give the software to somebody, you know that it will work on their server. I think this is very important.
One other thing about mod_perl, which i am not really well informed. It looks like mod_perl is not very friendly with virtual hosting. php-apache integration is much more better. Even though perl is much faster and better than php, the comparison is made as CGI against mod_php and perl loses.
Re:My opinion and experience
hfb on 2001-07-13T13:40:43
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?
If it's so popular, why is noone looking for it?
hfb on 2001-07-13T14:09:43
The CPAN search engine stats do not show this module having the minimum of 300 queries to list it which is curious.
Re:My opinion and experience
yudel on 2001-07-13T15:09:59
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.
Perl's not just for sysadmins anymore
ziggy on 2001-07-13T16:20:29
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.
Perl's not just for hard-core programmers either
hfb on 2001-07-13T18:38:28
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 bad goal.
I can't think of one major OS that has a standard core distribution with the OS of either Python or PHP and inclusions of extra libraries should probably be made with the vendors in mind as well.
Why not make a bundle or SDK or a BSD port package instead?
Re:Probably a good idea
xanthos on 2001-07-14T03:50:34
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.
Re:mod_perl might suffer
paulclinger on 2001-07-14T23:21:39
> 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 implements the same interface as XML::Parser it can be used in other projects too.
As for moving into core, I'm not sure this is right thing todo. CPAN is easy to use and webservices is not so widespread to benefit majority of Perl users. We can talk about it in SanDiego.
Paul.
Re:If it's so popular, why is noone looking for it
paulclinger on 2001-07-14T23:35:04
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.
Soap::Lite is already in the core for ActiveState
speters on 2001-07-18T01:13:57
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 would you like it if there were two different CGI or DBI packages? I know I probably would not be working with Perl half as much, especially in open source projects, if I had to constantly navigate between multiple packages that accomplished the same thing.
Re:Soap::Lite is already in the core for ActiveSta
pudge on 2001-07-20T13:08:49
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
:-).
Re:My opinion and experience
bill on 2001-07-20T15:20:46
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 for using the service. That is the dame argument that gave M$ the PC market.
Most businesses like buncled software. They "know" it works out of the box, and they do not have to mess with it beyond that (in theory). Correct or not does not matter, it is how things are in most cases.
Myabe the real solution it to provide different downloadable bundles (bare bones, database user, internet service provider,
...) so that the option rests in the end users hands, yet the "business" user still can get the whole thing in one "safe and easy" package. I know this presents its own set of issues and I am not able to provide suggestions for even half of them, but it is an idea.
I happen to really like Perl. It saves development time and cuts down on many serious issues that I run into with C, Java and other languages. But, I am being forced to use those languages more often because of lazy site installations.
Re:Soap::Lite is already in the core for ActiveSta
speters on 2001-08-09T21:01:19
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 competing packages were released. It would be nice if the market (e.g. Perl developers) would decide, but I have a nasty feeling that it won't soon. My guess is that I may be trying to put together projects where one team is using one XML-RPC package, and the other team is using the other.
