Re: p5ee list active
Nathan Torkington wrote: > The list's goal is to create the Perl 5 Enterprise Extensions. > Send mail to [EMAIL PROTECTED] to join. When we've decided > on a path and start to code, I'll have a CVS repository created. any reason for hardcoding 5 in the name? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Newbie having problems
John Michael wrote: > I have seen and read through the guide, but will read through it again as > you have suggested. > I do have use stricts in my scripts. > > I also get a lot of these things when I run it with the -w option. > > ;' called at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm > line 113 > Apache::PerlRun::compile('Apache::PerlRun=HASH(0x8a44a5c)', > 'SCALAR(0x885825c)') called at > /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 289 > Apache::PerlRun::handler('Apache=SCALAR(0x8385200)', 137931400, > 'Apache::PerlRun', 'Apache=SCALAR(0x8385200)') called at lib/file_ops.pl > line 82 > require 0 called at lib/file_ops.pl line 82 > Subroutine check_availability redefined at lib/file_ops.pl line 106. > require lib/file_ops.pl called at > /home/usr1/digital/membersurl/perl/content_manager/handler.pl line 28 > require 0 called at > /home/usr1/digital/membersurl/perl/content_manager/handler.pl line 20 > eval 'package > Apache::ROOTmembersurl_2ecom::perl::content_manager::handler_2epl;use Apache > qw(exit); > #line 1 /home/usr1/digital/membersurl/perl/content_manager/handler.pl > > My error log will fill up fairly quick. I am also using: > Apache::exit() > with > use Apache qw(exit) > and this seems to be causing errors as well. well, it seems that you have misread the guide. It says that you don't use Apache::exit() with registry and friends (perlrun *is* a registry friend :) you just use a plain exit() and perlrun will do the work for you. as for the warning in your error log, make them disappear by cleaning your code, through attending each and every report and making Perl happy when it complains. You're looking for a trouble if you make the warnings disappear by disabling warnings. Also don't use -w but PerlWarn On. But it's all in the guide, so I won't repeat it here. > Thanks > JM > > - Original Message - > From: "Ged Haywood" <[EMAIL PROTECTED]> > To: "John Michael" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, October 23, 2001 3:07 PM > Subject: Re: Newbie having problems > > > >>Hi there, >> >>On Tue, 23 Oct 2001, John Michael wrote: >> >> >>>I am new to mod-perl and am trying to migrate some pretty large >>>image scripts I have written to mod-perl. >>> >>Have you come upon the Guide? >> >>http://perl.apache.org/guide >> >>It's a fairly weighty document by now but most of what you want will >>be in there. >> >> >>>Would it be easier to migrate straight over to apache::registry? >>> >>It might be less trouble to start writing handlers. Apache::Registry >>can be intolerant. I take it you have "use strict;" in your scripts? >> >>73, >>Ged. >> >> -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Using non-response handler only
Ged Haywood wrote: > Hi there, > > On Tue, 23 Oct 2001, Issac Goldstand wrote: > > >>Just out of curiosity: are there any efficiency issues regarding >>using mod_perl for the exclusive use of a phase other than the >>response? In other words, if I want a script to do something other >>than return a static page from a file, are there >>advantages/disadvantages to using mod_perl over C? >> > > Perl is good if you want to whip up an appetising dish in a jiffy. If > you can do it in C, by all means do. It will likely be faster and use > a LOT less resources on the machine. Ducks and runs for cover :) Why, Ged? If I understand correctly Issac's question was whether it makes sense to use Perl in other than response handlers performance/efficiency wise. Of course it does and a big part of the eagle book is about this. Why writing something in C, when you get about the same speed performance in Perl. Especially if you talk about using Apache API in Perl. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: When to use 'use' for accessing modules?
Perrin Harkins wrote: > Chris Allen wrote: [...] > > Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar > > in httpd.conf? > > Yes. Are you sure? I experimented a few months ago, and found that $ENV{foo}='bar'; would only last in each child until the first request of the child completed. Steve -- Steve Piner Web Applications Developer Marketview Limited http://www.marketview.co.nz
Somewhat relevant
Folks, if this looks like an off topic, my apologies in advance... I have written an accessing scheme that checks for the existence of couple of cookies and if not present, the user is rerouted to a login page. So far simple stuff. The problem is that my boss is saying that it should work with a CGI script or a PHP script (legacy codes that are too many to port to mod_perl today). The basic mechanism behind my script is returning an error constant 403 in case the cookies are missing. Now, PHP, according to my boss, is very similar to a CGI script, so how does one throw an error (of any kind) that would cause Apache to generate its famous error page from a CGI program? Thanks in advance... -r
RE: newbie having problems
I had a routine in the beginning of the program to initialze my variable hash and query param like so: ## initialize globals ##foreach (keys %VAR){$VAR{$_} = "";} I did this so that these variables would not propogate to other instances of the script. This was causing the error. I removed it and added a this small sub: sub clean_up {undef %VAR;Apache::exit();} Is this the correct way to do this or even necessary? The Apache::exit() function is still causing an error, but the script runs and works but is evidently not exiting gracefully. I am running under apache::perl envir. Also, I am running the script in an eval{ } block in order to trap errors in the $@ variable. IS this ok practice in mod-perl? Thanks JM
namespace-troubles
I run into deep namespacetroubles I understand onyl vaguely and I cant workaround: I have a script running under mod_perl that is called via two domains. www1.domain.at/ www2.domain.at/sub/ both of the above addresses lead to the very same script (its the same file on the disk, not a copy). When I call the first adress all is working fine, but as soon as I call the second adress I get a server-error. Restarting apache and I try the second first: running fine, but as soon as I call the first: server-error. The log reveals: Undefined subroutine &Apache::ROOTwww1_2domain_2eat::main called at /data/public/stage2/fetch.pl line 9. or Undefined subroutine &Apache::ROOTwww2_2edomain_2eat::editeinstieg::main called at /data/public/stage2/fetch.pl line 9. my script is structured like that: fetch.pl: require fetch.lib.pl main(); - ---fetch.lib.pl: sub main{ do everthing here } 1; As far I can see, the second call does not load the lib anymore, cause it was already loaded on the first call. Unfortunately it was loaded to a different namespace, so the script doesnt find it. What can I do ? I need this different domains, cause the script-action depends on the calling domain. The reason why I splitted in script/lib is a document at apache.org that recommends this to avoid a nested-sub-problem under mod_perl. I wonder if providing the lib-file as module (use instead of require) would be a solution, but I guess not. Can the above problem occure with modules too ? If two scripts call the same module, is it only loaded on the first call and the second script fails ?? thnx, peter -- mag. peter pilsl phone: +43 676 3574035 fax : +43 676 3546512 email: [EMAIL PROTECTED] sms : [EMAIL PROTECTED] pgp-key available
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 03:38 AM 10/24/2001, Stephen Adkins wrote: >At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: > >Stephen Adkins wrote: > > > >> If no one suggests an appropriate list, I propose starting a "p2ee" group > > > > > >Can I just say that P2EE is a horrible, horrible name? It includes the > >Java version number (when is J3EE coming out?), as well as Sun's > >desperate attempt to make it sound like something you buy ("Edition") > >rather than simply a collection of APIs. > > > >Something simple, like Perl Enterprise Project or Perl Enterprise APIs > >makes more sense to me. > >Hi, > >Several of you have made the same good point. >And now the naming flame war has already begun... ;-) > >Unless there is violent opposition, the name will be > >Perl Enterprise Framework > >I would rather name it after the outcome (Framework) >than the process (Project). > >The mailing list will be > >[EMAIL PROTECTED] (preferred) >or >[EMAIL PROTECTED] (in case Nathan already has it set up) > >If this seems reasonable, let's not flood the list with "ok with me" >messages or "how about 'foo'?" messages. > >Stephen I think this name and mailing list is excellent and much better than P2EE. The mere fact that there is an endorsed perl.org mailing list for people who wish to ask about enterprise issues (even without a specific standard) is a huge step further in terms of making people aware that Perl CAN BE used for the enterprise. That is, there is a definite perception difference between [EMAIL PROTECTED] and [EMAIL PROTECTED] [EMAIL PROTECTED] has a perception of being endorsed as a place for a standard rather than just a single couple of people's ideas on sourceforge.com (of which there are thousands) and is likely to get more attention.
p5ee list active
The list's goal is to create the Perl 5 Enterprise Extensions. Send mail to [EMAIL PROTECTED] to join. When we've decided on a path and start to code, I'll have a CVS repository created. Nat
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
I'm surprised that no one has, jokingly, suggested PEE. Sorry, couldn't resist. :) -- === "If you put three drops of poison into a 100 percent pure Java, you get - Windows. If you put a few drops of Java into Windows, you still have Windows." -- Sun Microsystems CEO, Scott McNealy __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
"Robert Landrum" <[EMAIL PROTECTED]> wrote: > ... A name is pretty important > and if it's acronym isn't easily recognized, it isn't going to gain > the support of developers. J2EE is catchy, so we need something > catchy. PEF isn't nearly as catchy as P2EE or P5EE or PEA (Perl > Enterprise API), but maybe I'm just crazy. howsabout: p5ice ? Perl 5 Integrated Classes for the Enterprise or mebbe: Interface Client for Enterprises possibly: Insane Community of Entrepeneurs or even: Icky Commercialized Edition i can already see all the cool "Ice-ey" perl logos with icicles hanging from their frosted fonts :-) -dave
Re: Newbie having problems
I have seen and read through the guide, but will read through it again as you have suggested. I do have use stricts in my scripts. I also get a lot of these things when I run it with the -w option. ;' called at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 113 Apache::PerlRun::compile('Apache::PerlRun=HASH(0x8a44a5c)', 'SCALAR(0x885825c)') called at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 289 Apache::PerlRun::handler('Apache=SCALAR(0x8385200)', 137931400, 'Apache::PerlRun', 'Apache=SCALAR(0x8385200)') called at lib/file_ops.pl line 82 require 0 called at lib/file_ops.pl line 82 Subroutine check_availability redefined at lib/file_ops.pl line 106. require lib/file_ops.pl called at /home/usr1/digital/membersurl/perl/content_manager/handler.pl line 28 require 0 called at /home/usr1/digital/membersurl/perl/content_manager/handler.pl line 20 eval 'package Apache::ROOTmembersurl_2ecom::perl::content_manager::handler_2epl;use Apache qw(exit); #line 1 /home/usr1/digital/membersurl/perl/content_manager/handler.pl My error log will fill up fairly quick. I am also using: Apache::exit() with use Apache qw(exit) and this seems to be causing errors as well. Thanks JM - Original Message - From: "Ged Haywood" <[EMAIL PROTECTED]> To: "John Michael" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, October 23, 2001 3:07 PM Subject: Re: Newbie having problems > Hi there, > > On Tue, 23 Oct 2001, John Michael wrote: > > > I am new to mod-perl and am trying to migrate some pretty large > > image scripts I have written to mod-perl. > > Have you come upon the Guide? > > http://perl.apache.org/guide > > It's a fairly weighty document by now but most of what you want will > be in there. > > > Would it be easier to migrate straight over to apache::registry? > > It might be less trouble to start writing handlers. Apache::Registry > can be intolerant. I take it you have "use strict;" in your scripts? > > 73, > Ged. >
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 3:38 PM -0400 10/23/01, Stephen Adkins wrote: >Several of you have made the same good point. >And now the naming flame war has already begun... ;-) This is a discussion. Something has been proposed and it needs a name. I'd hardly call this a flame war. A name is pretty important and if it's acronym isn't easily recognized, it isn't going to gain the support of developers. J2EE is catchy, so we need something catchy. PEF isn't nearly as catchy as P2EE or P5EE or PEA (Perl Enterprise API), but maybe I'm just crazy. Rob -- "Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former." --Albert Einstein
Re: Using non-response handler only
Hi there, On Tue, 23 Oct 2001, Issac Goldstand wrote: > Just out of curiosity: are there any efficiency issues regarding > using mod_perl for the exclusive use of a phase other than the > response? In other words, if I want a script to do something other > than return a static page from a file, are there > advantages/disadvantages to using mod_perl over C? Perl is good if you want to whip up an appetising dish in a jiffy. If you can do it in C, by all means do. It will likely be faster and use a LOT less resources on the machine. Ducks and runs for cover :) 73, Ged.
Re: Newbie having problems
Hi there, On Tue, 23 Oct 2001, John Michael wrote: > I am new to mod-perl and am trying to migrate some pretty large > image scripts I have written to mod-perl. Have you come upon the Guide? http://perl.apache.org/guide It's a fairly weighty document by now but most of what you want will be in there. > Would it be easier to migrate straight over to apache::registry? It might be less trouble to start writing handlers. Apache::Registry can be intolerant. I take it you have "use strict;" in your scripts? 73, Ged.
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 02:28 PM 10/23/2001 -0400, Perrin Harkins wrote: >Stephen Adkins wrote: > >> If no one suggests an appropriate list, I propose starting a "p2ee" group > > >Can I just say that P2EE is a horrible, horrible name? It includes the >Java version number (when is J3EE coming out?), as well as Sun's >desperate attempt to make it sound like something you buy ("Edition") >rather than simply a collection of APIs. > >Something simple, like Perl Enterprise Project or Perl Enterprise APIs >makes more sense to me. Hi, Several of you have made the same good point. And now the naming flame war has already begun... ;-) Unless there is violent opposition, the name will be Perl Enterprise Framework I would rather name it after the outcome (Framework) than the process (Project). The mailing list will be [EMAIL PROTECTED] (preferred) or [EMAIL PROTECTED] (in case Nathan already has it set up) If this seems reasonable, let's not flood the list with "ok with me" messages or "how about 'foo'?" messages. Stephen
Re: Excellent article on Apache/mod_perl at eToys
Gunther wrote: > If you do not have a strongly typed system, then when you break apart and > rebuild another part of the system, Perl may very well not complain when a > subtle bug comes up because of the fact that it is not strongly typed. > Whereas Java will complain quite often and usually early with compile time > checking. I don't think there's an "objective" view about this. I also think the "it compiles, so it works" attitude is dangerous. You don't know it works until your unit and acceptance tests pass. I've been in too many shops where the "nightly build" was the extent of the quality assurance program. > Compile time checking can definitely be a friend of yours especially when > dealing with large systems. But it's also a friend that's judgemental > (strongly typed) so he's a pain to drag along to a party To me, strongly vs weakly typed is less descriptive than statically vs dynamically typed. For example, Java is missing "undef". It has NULL for pointers, but not "undef" for ints, chars, booleans, etc. Large systems often have unexpected initialization order problems which are not handled well by Java due to this missing feature. > Java's support for multi-threading makes writing servers feel fairly > trivial with no jumping through IPC::Shared memory stuff hoops to get > shared memory caches and the like.. you just synchronize on global data > structures. It's important to define the problem space for this discussion. I think Perl is really good for information systems, be they enterprise or not. I probably wouldn't program a real-time system in Perl. I might program it in Java. Here's a strong statement: Threads have no place in information systems. The NYSE is run on Tandem boxes. Tandem's OS does not have threads. The NYSE can process over a billion stock transactions a day. The EJB spec says you can't fire off threads in a bean. I think there's a reason for the way these systems have been architected. Threads are a false economy for systems which have to scale. As some people have joked, Java is Sun's way of moving E10K servers. SMP doesn't scale. As soon as you outgrow your box, you are hosed. A shared memory cache doesn't work well over the wire. In my experience, the only way to build large scale systems is with stateless, single-threaded servers. Rob
Using non-response handler only
Just out of curiosity: are there any efficiency issues regarding using mod_perl for the exclusive use of a phase other than the response? In other words, if I want a script to do something other than return a static page from a file, are there advantages/disadvantages to using mod_perl over C? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
RE: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
PEP! (Perl Enterprise Project)! I like it! Paul E Wilt Principal Software Engineer XanEdu, Inc. (division of Proquest Information and Learning) http://www.xanedu.com mailto:[EMAIL PROTECTED] 300 North Zeeb Rd Phone: (734) 302-6545 (800) 218-5971 x6545 Ann Arbor, MI 48106Fax: (734) 975-6440 -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 23, 2001 2:28 PM To: Stephen Adkins Cc: mod_perl List Subject: Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys Stephen Adkins wrote: > If no one suggests an appropriate list, I propose starting a "p2ee" group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy ("Edition") rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. - Perrin
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins wrote: > If no one suggests an appropriate list, I propose starting a "p2ee" group Can I just say that P2EE is a horrible, horrible name? It includes the Java version number (when is J3EE coming out?), as well as Sun's desperate attempt to make it sound like something you buy ("Edition") rather than simply a collection of APIs. Something simple, like Perl Enterprise Project or Perl Enterprise APIs makes more sense to me. - Perrin
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins writes: > That would be great (as long as perl.org can host the CVS too). > My concern was that perl.org might not be as specialized in hosting > development teams as sourceforge.net. Do you support "viewcvs" > or similar for web browsing of the CVS repository? cvsweb. You can see what we've got at cvs.perl.org. I'll ask Ask to add the list and repository. Cheers; Nat
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Nathan, At 11:06 AM 10/23/2001 -0600, Nathan Torkington wrote: >Stephen Adkins writes: >> If no one suggests an appropriate list, I propose starting a "p2ee" group >> on SourceForge. This gives us mailing lists and a CVS repository for the >> artifacts of the effort (which will mostly be specifications and >> documentation, with maybe some Bundle files). I would also submit the >> list information to "perl.org" for inclusion in the list of lists. > >We'd be glad to host it at perl.org. If that's cool with you, I'll >ask Ask to create the mailing list and CVS repository on perl.org. >Once we have something to show, we can get a website too. > >I'd imagine the CVS would include code we write, snapshots of which >would be periodically released to CPAN. Anyway, that's for the list >once we have it. > >Nat That would be great (as long as perl.org can host the CVS too). My concern was that perl.org might not be as specialized in hosting development teams as sourceforge.net. Do you support "viewcvs" or similar for web browsing of the CVS repository? Stephen
Re: Excellent article on Apache/mod_perl at eToys
Nathan Torkington <[EMAIL PROTECTED]> writes: > Leon Brocard writes: > > > Perhaps a port of JMS is in order. > > > > Interestingly, I've been thinking along the same lines. Spread > > (http://www.spread.org/) can be used for the publish/subscribe > > messaging domain but queueing seems to be important too. Straying a > > bit offtopic perhaps, but I wonder what would be involved... > > I like the idea of P2EE. If the goal is to provide the same features > as Java, why not just implement the Java messaging, transactions, > etc. APIs in Perl? That is, endeavour to have the same classes and > methods as Java, to the greatest extent possible. That'll also make > it possible for Java programmers to become Perl programmers, bwahaha. That's P5EE Is there a nice graphicy map of what actually constitutes J2EE onto which we can overlay the relevant perl bitz? -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com All the Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
On Tuesday 23 October 2001 18:21, Stephen Adkins wrote: > This issue of a P2EE specification has come up before > (and I participated in the discussion), but since it is off-topic for > the mod_perl list, I would appreciate some referrals of where to go to > discuss this. > > If no one suggests an appropriate list, I propose starting a "p2ee" group > on SourceForge. This gives us mailing lists and a CVS repository for the > artifacts of the effort (which will mostly be specifications and > documentation, with maybe some Bundle files). I would also submit the > list information to "perl.org" for inclusion in the list of lists. FWIW, (given the fact that we're talking about talking about it, I guess it's the moment for more-or-less useless ideas) I'd prefer it not to be called p2ee. It sounds more like a copy thing, and copies aren't good. What about EnterPerl or something like that ? In any case, please create the specific list before we start discussing the name here ;-) -- ___ Robin Berjon <[EMAIL PROTECTED]> -- CTO k n o w s c a p e : // venture knowledge agency www.knowscape.com --- Prediction is very difficult, especially of the future. -- Niels Bohr
Re: Excellent article on Apache/mod_perl at eToys
Matthew Kennedy wrote: > On Mon, 2001-10-22 at 21:27, Perrin Harkins wrote: > >>It sounds like the limitation there is that you're interfacing with systems >>that can't notify you when something new happens. That's not Perl's fault. >>If you wrote your daemons in Java alpahabet soup, they'd still have to poll >>the pop3 server. >> > > Well, I'd more likely be using a standard javamail API within the > context of a EJB server. There is a fairly rich set of call backs there > which mean I generally don't have to poll/sleep etc. Also true of the > java message service. I suppose the Java stuff does make it more obvious how to do that kind of thing. There are dozens of ways to have some perl code execute every time a message arrives at a mail server without polling (Mail::Filter, procmail, Perl pop3 server, maybe PerlMX, etc.), but there isn't any One True Perl Mail API. Pointing newbies in the right direction is the strength of standardized APIs, and it does seem to have helped Java gain acceptance. There are commercial JMS implementations that simply poll database tables, but most people don't seem to mind as long as that's all hidden behind the standard JMS API. So, maybe a version in Perl would be a useful thing. - Perrin
Re: Excellent article on Apache/mod_perl at eToys
At 10:11 AM 10/23/01 -0600, Nathan Torkington wrote: >Leon Brocard writes: > > > Perhaps a port of JMS is in order. > > > > Interestingly, I've been thinking along the same lines. Spread > > (http://www.spread.org/) can be used for the publish/subscribe > > messaging domain but queueing seems to be important too. Straying a > > bit offtopic perhaps, but I wonder what would be involved... > >I like the idea of P2EE. If the goal is to provide the same features >as Java, why not just implement the Java messaging, transactions, >etc. APIs in Perl? That is, endeavour to have the same classes and >methods as Java, to the greatest extent possible. That'll also make >it possible for Java programmers to become Perl programmers, bwahaha. The servlet API has been mostly(?) translated into perl by Brian Moseley. The homepage is http://libservlet.sourceforge.net/ and it's available on CPAN. The docs look a little parse at the moment, but kudos to Brian for the work done so far! Now if only I could figure out a good test application to try it with... Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: [OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
Stephen Adkins writes: > If no one suggests an appropriate list, I propose starting a "p2ee" group > on SourceForge. This gives us mailing lists and a CVS repository for the > artifacts of the effort (which will mostly be specifications and > documentation, with maybe some Bundle files). I would also submit the > list information to "perl.org" for inclusion in the list of lists. We'd be glad to host it at perl.org. If that's cool with you, I'll ask Ask to create the mailing list and CVS repository on perl.org. Once we have something to show, we can get a website too. I'd imagine the CVS would include code we write, snapshots of which would be periodically released to CPAN. Anyway, that's for the list once we have it. Nat
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 23 Oct 2001, Nathan Torkington wrote: > Of course, we couldn't call it a Java bean. They'd have to be Camel > droppings. :-) Perl Jewels (Joules?) -dave /*== www.urth.org We await the New Sun ==*/
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 2001-10-23 at 10:09, Gunther Birznieks wrote: > At 08:46 PM 10/23/2001, Rob Nagler wrote: > >I don't quite understand the difference between worflow in the front-end and > >workflow in the back-end. They both change. The danger of making one part > >of the system easier to change is that people tend to "cheat". They won't > >put the business logic in the back-end if it takes twice as long. > > Yes, people can cheat. But generally the workflow that is most likely to > change is the UI based workflow. UI isn't just about templates, it's a lot > about how you go from one screen to the next, or not. > > Actually business logic is a bit of a misnomer because there is plenty of > business logic in the front-end from your choice of fields to the > javascript to the UI workflow. I agree. Basically there's front end business logic which defined the work flow of the client's end (web server/web browser etc). And then business logic in the middle tier. I've been using Apache/Jakarta Struts for the front end business stuff, a row of "session beans" (java speak for purely process related, not data related objects) behind the client to model work flow and then another row of "entity beans" (java speak for data object persistence) to get at a rdbms. This arrangement has worked well for me. This approach makes "cheating" code look immediately out-of-place, and just downright embarrassing :) Is there a Perl equivalent to Struts? Mason seems to come close if you keep yourself disciplined somewhat. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: [OT] Perl daemons (was Re: Excellent article on Apache/mod_p
> >> Is anyone else using independent perl processes in a web app, or have strong > >> reasons not to? > > I use them for quite a few things. fork/exec works nicely in perl > (on unix at least), allows me to write daemons for most things. > Sure, our network is supported internally by a DNS daemon written entirely in perl which supports all standard TCP/UDP queries, frontended inside by an extensive web app interface and backended by a sql server to store the data. It does all the normal daemon stuff, forking and keeping track of it's kids, etc... What appears to be the primary NS's at our site actually query the inside DNS for their updates. Modifications to the NSDB via the web interface are pushed out to the primaries in real time within a few seconds. This has been running for several years, never even a hiccup. There are a multitude of other daemon and daemon like processes that support automatic updates for a variety of speciality web sites that reside on our servers. many of these processes are spread across multiple machines, each doing their little piece to complete the puzzle -- all written in perl for the stand-alones or mod_perl for the web apps. Michael [EMAIL PROTECTED]
[OT] P2EE Redux was: Excellent article on Apache/mod_perl at eToys
At 11:27 PM 10/23/2001 +0800, Gunther Birznieks wrote: >At 09:45 PM 10/23/2001, Perrin Harkins wrote: >>Matt Sergeant wrote: >>>OK, so what are we missing? ... >>Based on the comments I've seen here over the years, and some on Slashdot, >>the thing that seems to worry people the most is the lack of an obvious >>message queue API in Perl. I've seen plenty of implementations, but there >>isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. ... >I really would like to see a generally endorsed P2EE project which includes >SOAP::Lite as an interoperable webservices engine, a messaging engine, and >transaction engine. Authentication engine and Session engine would be quite >useful to include as well. Oh and Moseley's (sp?) servlets in Perl project >would be a cool one to include as well. That would make it compete pretty >much head to head with J2EE. Hi, This issue of a P2EE specification has come up before (and I participated in the discussion), but since it is off-topic for the mod_perl list, I would appreciate some referrals of where to go to discuss this. Last time this came up, I was referred to three different mailing lists (also, see http://lists.perl.org/). However, none of the lists were interested in the P2EE problem (including the PerlSDK list). If no one suggests an appropriate list, I propose starting a "p2ee" group on SourceForge. This gives us mailing lists and a CVS repository for the artifacts of the effort (which will mostly be specifications and documentation, with maybe some Bundle files). I would also submit the list information to "perl.org" for inclusion in the list of lists. Stephen
Re: Excellent article on Apache/mod_perl at eToys
Leon Brocard writes: > > Perhaps a port of JMS is in order. > > Interestingly, I've been thinking along the same lines. Spread > (http://www.spread.org/) can be used for the publish/subscribe > messaging domain but queueing seems to be important too. Straying a > bit offtopic perhaps, but I wonder what would be involved... I like the idea of P2EE. If the goal is to provide the same features as Java, why not just implement the Java messaging, transactions, etc. APIs in Perl? That is, endeavour to have the same classes and methods as Java, to the greatest extent possible. That'll also make it possible for Java programmers to become Perl programmers, bwahaha. Someone described Java beans to me as being more or less "classes that follow conventions on things like accessor names and methods to respond to events. Those conventions permit introspection and interoperability between two classes that have no a priori knowledge of each other." I like that idea, too. It'd be fun to see what kinds of UI (both GUI and web) things become easier with this kind of functionality. Of course, we couldn't call it a Java bean. They'd have to be Camel droppings. :-) Nat
Re: Excellent article on Apache/mod_perl at eToys
On Mon, 2001-10-22 at 21:27, Perrin Harkins wrote: > > It sounds like the limitation there is that you're interfacing with systems > that can't notify you when something new happens. That's not Perl's fault. > If you wrote your daemons in Java alpahabet soup, they'd still have to poll > the pop3 server. Well, I'd more likely be using a standard javamail API within the context of a EJB server. There is a fairly rich set of call backs there which mean I generally don't have to poll/sleep etc. Also true of the java message service. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
RE: Excellent article on Apache/mod_perl at eToys
On Mon, 2001-10-22 at 20:14, Robert Koberg wrote: > > > > For comparions, a nice aspect of j2ee applications IMHO is the > > "application server" tends to be more general. ie. the application > > server is not just the web server (as it is with mod_perl). I've found > > j2ee features such as message beans, queues and such especially useful > > for back-end work. For these reasons, I personally don't buy the > > argument that mod_perl makes an effective application server for a good > > sized task (your mileage will vary no doubt ;).> > > > What is stopping you from using both, if you want? Actually, I already do -- but not at the same time. The criteria I personally use is basically this: if the task doesn't involve more than one or two disparate system to be talked to, and a two tier model (apache and a rdbms for example) fits the problem well, then I'll chose Perl (mod_perl, Mason and *sometimes* ORBit's Perl bindings). If the app is to talk to a number of disparate systems and a variety of client types (stand alone app, web, wireless etc.) then generally I'll use the a J2EE app server etc. Of course there are will be exceptions. ORBit is a corba orb, BTW. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: @INC
"Plows, Sean (London)" wrote: > > How can I set this as my cgi's can't locate my libs? > > > Regards, > > > > Sean Plows Sean - try "use lib '/path/to/my/libs';" That should "append" your library path to @INC. Word on the street is that you NEVER EVER want to mess with @INC directly. Jon Robison !Uniphied Thought, LLC
Re: [OT] Perl daemons (was Re: Excellent article on Apache/mod_perl at eToys)
-- [EMAIL PROTECTED] on 10/23/01 10:23:18 -0500 >> >> Is anyone else using independent perl processes in a web app, or have strong >> reasons not to? I use them for quite a few things. fork/exec works nicely in perl (on unix at least), allows me to write daemons for most things. Why do you ask? sl
Re: Excellent article on Apache/mod_perl at eToys
At 10:36 PM 10/23/2001, Leon Brocard wrote: >Perrin Harkins sent the following bits through the ether: > > > Perhaps a port of JMS is in order. > >Interestingly, I've been thinking along the same lines. Spread >(http://www.spread.org/) can be used for the publish/subscribe >messaging domain but queueing seems to be important too. Straying a >bit offtopic perhaps, but I wonder what would be involved... One thing that would be interesting to me is an engine that can provide real time pricing feeds. It seems to me that jabber (chat engine) is actually a lot more powerful than being about chatting. Some applications are lonely and want instant messaging too. :) Queuing is important but for different reasons and usually different applications eg if your circuits are global. eg a London broker makes a transaction destined for Singapore, but has to go via Hong Kong and the London/HongKong circuit is only up every 5 minutes... Although this is not dissimilar to the resilience of a message delivered via SMTP relays.
[OT] Perl daemons (was Re: Excellent article on Apache/mod_perl at eToys)
> > Is anyone else using independent perl processes in a web app, or have strong > reasons not to? Our web application (Metadot) provides a number of functions that are fulfilled by a daemon written in perl. Among these are: collecting content from syndicated news channels, sending email messages to users about newly added content, retrieving email messages to add to site content, monitoring and cleaning database tables, etc. We run this daemon as a cron job every twenty minutes, and within it we have sections for tasks that are performed at hourly, daily and weekly intervals. The script is a bit messy but could still serve as a skeleton for similar ones for other applications. It's called metadotd.pl and is part of our open source distribution available from Metadot.net. Regards, Claudio
Re: Excellent article on Apache/mod_perl at eToys
At 09:45 PM 10/23/2001, Perrin Harkins wrote: >Matt Sergeant wrote: > >>OK, so what are we missing? > > >Based on the comments I've seen here over the years, and some on Slashdot, >the thing that seems to worry people the most is the lack of an obvious >message queue API in Perl. I've seen plenty of implementations, but there >isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. I think it's more than that. It's more of a general all around 'feeling' as I've said before. It's about people and it's about the standards. The thing about "Enterprise" applications is that there are many components to what "enterprise" means J2EE compromises a lot of standards and frameworks all in one and to read the books about them all would take several weeks at least. But at least I know that when I read a book on EJB, I know this is the plan and it's stable etc... whereas someone's particular idea of a transaction engine in Perl is just someone's idea of a transaction engine in Perl. It may be a good idea, but it's really quite scary to build a large system around something that may not have a lot of success stories around it. This is why Perrin's article is so good. Because it starts getting more high profile success stories out there. There really are otherwise not that many about Perl when compared to Java. And even then, let's also consider the programming base. When I advertise for Perl programmers, they generally just know how to do Web apps and it's pulling teeth to even get OO and Mod_perl capability. It has to be taught after such programmers are brought in. But with Java, it's quite rare to find a Java programmer that hasn't programmed at least their own minimal RMI server before. I have little doubt that this is because of the sheer amount of documentation for making an RMI server plus the fact that it is a true "standard" so people feel comfortable that it is supported in a large community. Remember that my email said, I "feel" better about coding middleware in Java than in Perl. Just as I "feel" better about coding front-end in Perl. This is a "feeling" and isn't necessarily something that can be quantified -- it is also about perception which is something that cannot be ignored. And part of it is about "soft" issues like knowing that I can find Java programmers at a dime a dozen who have done middleware coding before in Java. I think more success stories would help. I also think official endorsement by key members of the Perl community (eg Larry) would help certain projects. ie I believe SOAP::Lite is now the defacto standard SOAP Library for Perl that people would recommend anyone to use no? So why is it still SOAP::Lite and not moved and advocated into the SOAP namespace where it belongs and make it the defacto standard SOAP engine for Perl if it's proven itself? Of course, choice is part of what makes Perl fun. But fun isn't for everyone. eg when it comes to such niche libraries as middleware tools, it's not so fun to have choices if none of the choices are very easy to evaluate. It's much nicer for a programmer to be able to reliably choose a tool they feel is backed by a strong community beyond just the immediate few people who may have done X middleware for one project or group of projects for one company. I really would like to see a generally endorsed P2EE project which includes SOAP::Lite as an interoperable webservices engine, a messaging engine, and transaction engine. Authentication engine and Session engine would be quite useful to include as well. Oh and Moseley's (sp?) servlets in Perl project would be a cool one to include as well. That would make it compete pretty much head to head with J2EE. And then success stories on top of P2EE. Later, Gunther
Re: Excellent article on Apache/mod_perl at eToys
At 08:46 PM 10/23/2001, Rob Nagler wrote: > > is easier and more standardized, and well documented. But I "feel" like > > coding front-end web applications is much easier in Perl where the workflow > > bits change all the time. For this, I like using SOAP on the backend Java > > server and SOAP on the front-end Perl. > >I don't quite understand the difference between worflow in the front-end and >workflow in the back-end. They both change. The danger of making one part >of the system easier to change is that people tend to "cheat". They won't >put the business logic in the back-end if it takes twice as long. Yes, people can cheat. But generally the workflow that is most likely to change is the UI based workflow. UI isn't just about templates, it's a lot about how you go from one screen to the next, or not. Actually business logic is a bit of a misnomer because there is plenty of business logic in the front-end from your choice of fields to the javascript to the UI workflow. >To me, the major issue in Perl vs Java is dynamic vs static typing. Building >large scale systems in Perl is much like building them in Smalltalk or Lisp. >It takes a certain mindset. The lack of compiled interfaces means you need >much more discipline (e.g. unit testing). The payoff is big with Perl, >because >you can refactor more easily and quickly than in Java. I don't think refactoring in Perl is necessarily faster. Actually, it can be quite hard to refactor in Perl as well but for the opposite reason. If you do not have a strongly typed system, then when you break apart and rebuild another part of the system, Perl may very well not complain when a subtle bug comes up because of the fact that it is not strongly typed. Whereas Java will complain quite often and usually early with compile time checking. Compile time checking can definitely be a friend of yours especially when dealing with large systems. But it's also a friend that's judgemental (strongly typed) so he's a pain to drag along to a party In practice, I still think using a good framework, it's about as long to develop in Perl as it is in Java for a medium sized system. My only beef I have with Java and I still have it is that the debugging support is simply atrocious for web apps. Perl has many more debugging utilities and allows much greater introspection. When I develop in Java, the only reason it takes me about 20% longer is that I am restarting the server much more often than I do in Perl. >The libraries aren't much an issue. A good example is SOAP. SOAP is >middleware. It is standardized, documented, and the rest of it. You like >it for connecting Perl to Java, but why can't it be the other way around? >If it can be the other way around, why aren't Perl and Java equally adapted >to building middleware applications? Java's support for multi-threading makes writing servers feel fairly trivial with no jumping through IPC::Shared memory stuff hoops to get shared memory caches and the like.. you just synchronize on global data structures. Arguably, an overuse of threads has problems in itself, but in general, I think it is easier. It is also easier to find programmers who know how to code middleware that do Java and harder to find people who have coded middleware that are Perl programmers... so maybe the language would support it, but there is also a personnel issue. Later, Gunther
Re: Excellent article on Apache/mod_perl at eToys
Perrin Harkins sent the following bits through the ether: > Perhaps a port of JMS is in order. Interestingly, I've been thinking along the same lines. Spread (http://www.spread.org/) can be used for the publish/subscribe messaging domain but queueing seems to be important too. Straying a bit offtopic perhaps, but I wonder what would be involved... Leon -- Leon Brocard.http://www.astray.com/ Nanoware...http://www.nanoware.org/ ... Byte this (designer underware)
Re: Excellent article on Apache/mod_perl at eToys
Matt Sergeant wrote: > OK, so what are we missing? Based on the comments I've seen here over the years, and some on Slashdot, the thing that seems to worry people the most is the lack of an obvious message queue API in Perl. I've seen plenty of implementations, but there isn't a plug-n-play CPAN module for this. Perhaps a port of JMS is in order. - Perrin
Re: When to use 'use' for accessing modules?
Chris Allen wrote: > If site::products calls functions from site::customers, do I need > a 'use site::customers' in site::products, when I have already > done a 'use' in my startup.pl? No, but I always do. It's good documentation, to remind you that if you ever ran this code outside of mod_perl it would be necessary to have that 'use' in place. > site::products contains the line: > > @ISA=('site::base'); > > so that methods from site::base can be overridden in site::products. > > Do I need a 'use site::base' in site::products for this to work > correctly? Only if site::base has not been loaded already, but I always do it anyway, for the same reason as above. > Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar > in httpd.conf? Yes. > Experience has shown that I *don't* need the 'use' statements anywhere > other than startup.pl - but I am not sure why, and would find some pointers > to a discussion of this very useful. You don't need them because the modules they would load are already loaded. > I would also be interested to know that > if the 'use' statements *are* unnecessary, does including them add any extra > overhead of processing/memory?? There is a very fast check that happens once when the module containing the 'use' is called. It checks to see if the used module is already loaded (i.e. if it is in %INC). It also calls the used module's export function, unless you pass an empty list: use Foo (); You should avoid importing symbols all over the place, as explained in the Guide, but otherwise there is no significant overhead from having use statements all over the place. - Perrin
When to use 'use' for accessing modules?
I have a modperl site that accesses a number of modules. In my startup.pl I have: #!/usr/bin/perl -w use strict; use lib('/path/to/my/installation'); # 'site' directory is here use Apache::DBI; use Apache::StatINC; use site::customers; use site::orders; use site::products; use site::base; 1; None of the modules exports *any* symbols at all - all are called in the form: $product=site::products->new(23); $product->get('price'); First question: If site::products calls functions from site::customers, do I need a 'use site::customers' in site::products, when I have already done a 'use' in my startup.pl? Second question: site::products contains the line: @ISA=('site::base'); so that methods from site::base can be overridden in site::products. Do I need a 'use site::base' in site::products for this to work correctly? Third (unrelated) question. Is $ENV{foo}='bar'; in startup.pl equivalent to PerlSetEnv foo bar in httpd.conf? --- Experience has shown that I *don't* need the 'use' statements anywhere other than startup.pl - but I am not sure why, and would find some pointers to a discussion of this very useful. I would also be interested to know that if the 'use' statements *are* unnecessary, does including them add any extra overhead of processing/memory?? Many thanks, Chris Allen.
Re: Excellent article on Apache/mod_perl at eToys
Matthew Kennedy wrote: > Secondly, I've worked on a good-sized commerce site with > mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end > of the site involves several standalone perl programs running as > daemons. What's even worse is; most of them have to sit in poll/wait > loops waiting on message from external systems (such as pop3 servers, > ccvs etc.) Why exactly is that a dirty secret? I've been thinking about writing one or two standalone poe daemons to handle interfacing with other systems, and it doesn't seem like such a bad idea. Code to talk to or listen to web clients can be in mod_perl, and code to talk to other systems can be outside. I've even thought about taking some of the database objects out of mod_perl, but am less sure about doing that. Is anyone else using independent perl processes in a web app, or have strong reasons not to?
Re: Excellent article on Apache/mod_perl at eToys
> is easier and more standardized, and well documented. But I "feel" like > coding front-end web applications is much easier in Perl where the workflow > bits change all the time. For this, I like using SOAP on the backend Java > server and SOAP on the front-end Perl. I don't quite understand the difference between worflow in the front-end and workflow in the back-end. They both change. The danger of making one part of the system easier to change is that people tend to "cheat". They won't put the business logic in the back-end if it takes twice as long. To me, the major issue in Perl vs Java is dynamic vs static typing. Building large scale systems in Perl is much like building them in Smalltalk or Lisp. It takes a certain mindset. The lack of compiled interfaces means you need much more discipline (e.g. unit testing). The payoff is big with Perl, because you can refactor more easily and quickly than in Java. The libraries aren't much an issue. A good example is SOAP. SOAP is middleware. It is standardized, documented, and the rest of it. You like it for connecting Perl to Java, but why can't it be the other way around? If it can be the other way around, why aren't Perl and Java equally adapted to building middleware applications? Rob
Newbie having problems
Hi I am new to mod-perl and am trying to migrate some pretty large image scripts I have written to mod-perl. I am attempting first to ge them to run correctly under. Apache::PerlRum The scripts run, but sometimes through server errors. I am getting the following errors. [Tue Oct 23 06:57:27 2001] [error] PerlRun: `Not a CODE reference at /home/usr1/digital/membersurl/perl/content_manager/handler.pl line 57.' [Tue Oct 23 06:57:27 2001] [error] Can't locate object method "uri" via package "Apache::PerlRun" at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 212. Here is the code at line 57 in the script I have written handler.pl &assign_values(&get_file("vars/variables.info")); It calls these two subs to load variables into the script. #sub get_file {my $file_name = shift;my @array;open (IFH, "$file_name") || &error("Cannot open $file_name for get.","$!"); @array = ;close IFH;return @array;}sub assign_values {my @array = @_;foreach (@array) { my $name = ""; my $value = ""; chomp; ($name, $value) = split(/=/); $value =~ tr/+/ /; $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg; $value =~ s///g; $VAR{$name} = $value;}return 1;} I can't find out why I am getting these errors. I can usually do an imediate refresh of the browser and the script will run ok. I am trying to get the scripts to run under apache::perl. Would it be easier to migrate straight over to apache::registry? Thanks John michael
RE: Excellent article on Apache/mod_perl at eToys
> However, I would have to say that I "feel" like coding > middleware in Java > is easier and more standardized, and well documented. OK, so what are we missing? I feel like we're getting pretty close to standardisation of middleware development with environments like POE (which rocks, but is under-documented and still quite hard to grok), but maybe there's more we can do - and having people like yourself who cross the divide can only help if you give us more information :-) One thing I know is missing in the XML world is an equivalent to JAXP. Hopefully we'll put that right fairly soonish. I guess there's equivalent issues in the whole Perl "middleware" environment, but we don't really know what they are. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: Excellent article on Apache/mod_perl at eToys
At 09:14 AM 10/23/2001, Robert Koberg wrote: > > For comparions, a nice aspect of j2ee applications IMHO is the > > "application server" tends to be more general. ie. the application > > server is not just the web server (as it is with mod_perl). I've found > > j2ee features such as message beans, queues and such especially useful > > for back-end work. For these reasons, I personally don't buy the > > argument that mod_perl makes an effective application server for a good > > sized task (your mileage will vary no doubt ;).> > > >What is stopping you from using both, if you want? It's generally quite tough to convince management that maintaining two sets of knowledge -- Java and Perl is cost effective. I suppose it depends on the size of the organization but "consolidation" of "standards" in an organization is an age-old thing (eg move all servers to NT, move everyone to Java, etc...) Whether this actually saves costs is a bit of an arguement probably not best for this mailing list. However, I would have to say that I "feel" like coding middleware in Java is easier and more standardized, and well documented. But I "feel" like coding front-end web applications is much easier in Perl where the workflow bits change all the time. For this, I like using SOAP on the backend Java server and SOAP on the front-end Perl. YMMV. And I don't know that many organizations which will allow such a heterogeneous environment unless a vendor installs it as a turnkey solution and is willing to deal with all the support. __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/