Re: [ANNOUNCE] new site: scaling mod_perl (+tool: mod_perl +DBD::Oracle)

[Matt Sergeant]

On Fri, 8 Dec 2000, Perrin Harkins wrote:

> > 1. Performance benchmarking code. In particular, I'm looking for tools
> that
> > can read in an apache log, play it back realtime (by looking at the time
> > between requests in the apache log), and simulate slow & simultaneous
> > connections. I've started writing my own, but it would be cool if
> something
> > else out there existed.
>
> The mod_backhand project was developing a tool like this called Daquiri.

I also have a tool here that you install as a TransHandler, and it reads
querystring and POST data [*] and saves it to an XML log file, then it
appends to the PerlHandler phase and dumps the output that would go to the
browser to the same XML log file (of course this requires the output to
be stored somewhere, like Apache::Filter does, rather than printed direct
to the browser). Then there's a little playback tool. Its a bit specific
to the app I'm working on, because there's code in place to make
Apache::Request a singleton and also collect the output, but I could be
persuaded to open it up to people.

[*] using Apache::Request at the moment - but we need to modify
Apache::Request to be a singleton as it can't be instantiated twice in the
same application at the moment.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: debuggers

[Matt Sergeant]

On Fri, 8 Dec 2000, Bruce W. Hoylman wrote:

> > "Dave" == Dave Rolsky <[EMAIL PROTECTED]> writes:
>
> Dave> On Thu, 7 Dec 2000, martin langhoff wrote:
> >> I wonder how do those hardcore guys that develop using handlers
> >> debug.  Mhhh. They must write 'perlfect' code, I guess, and/or
> >> understand those cryptic debuggers ...
>
> Dave> I just do a lot of debugging via warn statements and looking
> Dave> at the error logs.
>
> My BEGIN block looks like this.  I realize IO is rather bulky, but I
> like it and the environment I'm in isn't *that* busy where it makes a
> significant impact.
>
> BEGIN {
>
>   # Wash the PATH.
>   $ENV{'PATH'} = '/opt/gnu/bin:/usr/local/bin:/usr/bin';
>   $ENV{'CDPATH'} = '';
>   $ENV{'ENV'} = '';
>
>   use IO::File;
>   use CGI::Carp qw(carpout fatalsToBrowser carp);
 ^^^

Bye bye exception handling.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help needed with MAP expression

[Matt Sergeant]

On Thu, 7 Dec 2000, bari wrote:

> Hi there,
> Can any one help me what this MAP function does...
>
>  map(/^[\.\d]+$/ ? td({-align=>'right'}, $_) : td($_), @$_)

$_ contains an array ref. It loops through each entry in the array ref. If
the entry is a number (by the above regexp's naive view of numbers), it
maps it to number, otherwise it maps it to
value.

The use of $_ as the container for the array ref, while using map (which
gives you a $_ inside the map expression) is scary scary obfuscated
nastiness and deserves a slap for whoever wrote it.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: debuggers

[Matt Sergeant]

On Thu, 7 Dec 2000, martin langhoff wrote:

> Perrin Harkins wrote:
> >
> > I don't know how easy it is to make it play with
> > mod_perl though.  Apache::Debug normally just dumps you into the shell
> > debugger.  Maybe setting an environment variable would do it.
> >
>
>   I've always considered mod_perl to be completely debugger-unfriendly.
> That's why I write modules that I can test from a standard script, and
> then call those modules from Embperl pages or Registry scripts.
>
>   I wonder how do those hardcore guys that develop using handlers debug.
> Mhhh. They must write 'perlfect' code, I guess, and/or understand those
> cryptic debuggers ...

Personally I've always relied on sending debug messages to the log, and
then staring at the code for a few minutes/months.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange problem with IE 5

[Matt Morton]

ek wrote:
> 
> Hello all,
> i'm trying to build a standard system: apache-1.3.14 with
> compiled in mod_perl-1.24_01 on RedHat linux 6.2
> 
> If i build apache without mod_perl everything works fine. But if
> build apache with mod_perl, IE 5.0 fails to load pages from the
> server. I can only see blank page without any error message. This
> happens with all html documents - even static.
> 
> The record in access_log:
> 
> 192.168.2.11 - - [date] "GET /file.htm HTTP/1.1" 200 8731 "-"
> "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0")"
> 
> Everything is fine except the byte count after the response
> code - its is always less than the actual document size.
> 
> I tried to telnet to the server and use HEAD, GET, etc. -
> everything works fine.
> 
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> HEAD /file.htm HTTP/1.1
> HOST: 192.168.2.50
> 
> HTTP/1.1 200 OK
> Date: Thu, 07 Dec 2000 18:58:26 GMT
> Server: Apache/1.3.14 (Unix) mod_perl/1.24_01
> Last-Modified: Wed, 06 Dec 2000 16:05:10 GMT
> ETag: "7e7-0-3a1ea9cb"
> Accept-Ranges: bytes
> Content-Length: 0
> Content-Type: text/html
> 
> What could be wrong here? What should i check?
> 
> Expecting help -
> 
> ek.
> 
> -----
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


You might want to check your error logs and post that. :)

Matt

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Matt Sergeant]

On Thu, 7 Dec 2000, Robin Berjon wrote:

> At 07:56 07/12/2000 -0700, Nathan Torkington wrote:
> >I'd rather see us find some way to churn out perl and mod_perl
> >programmers.  For instance, release a beginner class on Perl and
> >mod_perl and have local Perlmongers lead classes.  I have my slides
> >from the University of Perl, which I'd contribute to such an effort
> >(they're pretty closely based around the Eagle book, and some of the
> >details should be replaced with sections on Mason et al.).
>
> That's where PerlMonth was cool. It's a pity that it disappeared. Maybe
> that stuff should go on take23 now.

I'd love that. In fact anything that anyone had waiting to go onto
PerlMonth please drop a mail to [EMAIL PROTECTED] and we'll get you
published. (assuming that PerlMonth isn't going to resurrect itself)

NB: Don't mail me direct - take23 is a group effort.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Certification

[Matt Sergeant]

On Thu, 7 Dec 2000, J. J. Horner wrote:

> If I'm way off base, please let me know.  I'm spending considerable
> brain power on this idea and if I'm wasting it, I need to know.  I
> don't have much spare brain power and I could use it to try to figure
> out my wife . . .

Ask yourself this question: Are you in need of a mod_perl job? If so, I'm
willing to bet that there are employers who would snap you up in a second.

As has been said a few times here, certification is pretty pointless
unless you need some distinguishing factor. With mod_perl, the
distinguishing factor is that you're available!

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

On Thu, 7 Dec 2000, Jimi Thompson wrote:

> Matt,
>
> Everything required to make the module work ought to be included in
> the package or at least cross referenced to it.  I have been having a
> problem in which I have had to manually resolve module dependencies on
> a Solaris 2.6 box.  It went through several layers with several
> candidates for each layer.  It's taken me a couple of months to get
> here.
>
> If you want corporate america to buy in to Perl, which seems to be the
> general gist of this thread, and not to loose any of the freedom you
> have in coding Perl, then you are going to have to find a way to make
> Perl easier to use.  If it stays this hard, most employers are not
> going to let their precious IT staff devote time and energy to doing
> things in Perl that they can buy off the shelf elsewhere.
>
> It's really been an ugly process.  My suggestion, I think that CPAN
> could make things a whole lot easier by simply asking the folks who
> wrote the module to link to the things it's dependent on.  I also
> think that CPAN could make a good many folks lives easier by listing
> system requirements, when known.
>
> My point is that if things have been this bad for me, an end user (Joe
> Small Business Owner) would have given long ago and used php for his
> web site because he can probably figure that out.

I'm starting to come around to this now, especially with AxKit which
relies on so many modules. I used to be a big fan of Activestate's PPM
system (still am, only I don't use NT any more). I just wish it could work
reliably on Linux, with so many different linux versions around.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[OT] Take23.org DNS

[Matt Sergeant]

Thanks for all the offers, I have it sorted now (should propogate some
time later today or tomorrow).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] Take23

[Matt Sergeant]

On Wed, 6 Dec 2000, Matt Sergeant wrote:

> OK, so this isn't really much of an announcement, since its still the same
> web site. Anyway, I'm renaming modperl.sergeant.org to take23.org.
>
> DNS should propogate shortly. Until then its available at
> modperl.sergeant.org (and will continue to be available there).

Looks like DNS isn't working at all... I'm a complete DNS moron - is there
anyone out there willing to offer me very a simple DNS setup on their
primary and secondary servers?

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCE] Take23

[Matt Sergeant]

OK, so this isn't really much of an announcement, since its still the same
web site. Anyway, I'm renaming modperl.sergeant.org to take23.org.

DNS should propogate shortly. Until then its available at
modperl.sergeant.org (and will continue to be available there).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Matt Sergeant]

On Wed, 6 Dec 2000, brian moseley wrote:

> On Wed, 6 Dec 2000, Matt Sergeant wrote:
>
> > You can't, but thats because I believe in the CPAN model
> > - use pre-written components. I don't believe shipping
> > all those components in AxKit (and there are a fair
> > number required) is the right solution. Maybe I'm
> > mistaken.
>
> that's why Bundle::AO is nice.

What does Bundle::AO give you that setting PREREQ_PM correctly wouldn't?

> it's stubborn adherence to models like this, tho, that keeps
> us from making generational advances rather than incremental
> ones.

Agreed... I *do* wish that more perlers would be open to binary modules -
the Activestate PPM model. While there were regularly problems with PPM,
the vast majority of module installations were incredibly trivial.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

On 6 Dec 2000, David Hodgkinson wrote:

> Matt Sergeant <[EMAIL PROTECTED]> writes:
>
> > On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:
> >
> > > I haven't looked at AO or AxKit, but if I can untar either one of them and
> > > just get to work, that will rule.
> >
> > You can't, but thats because I believe in the CPAN model - use pre-written
> > components. I don't believe shipping all those components in AxKit (and
> > there are a fair number required) is the right solution. Maybe I'm
> > mistaken.
>
> Isn't that just a question of getting a Bundle::AxKit together?
>
> Or is that an egg-sucking thing...

Bundles are for when you don't have a dependency tree, which AxKit has.
But the real problem is the non-perl modules. And the fact that AxKit
doesn't seem to work with PHP. And the Apache-expat bug/problem. All these
things make installing AxKit a bit non-trivial.

I quite like the Zope model - a single distribution which just includes
and installs everything you need in a single place. You get python, the
httpd, the database, everything. Of course if you have more complex needs,
like running Zope from within Apache, you need to do some extra work, but
out of the boz Zope gives you a great system that just runs. We could do
that with AxKit - just ship it with Apache, mod_perl, the whole lot. But I
don't think that would appeal to Perl people somehow. Thoughts?

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:

> On Tue, 5 Dec 2000, brian moseley wrote:
>
> > On Tue, 5 Dec 2000, Perrin Harkins wrote:
> >
> > > > Transaction support for your business logic is easy in J2EE. It's not
> > > > clear how you do this in Perl?
> > >
> > > Use an RDBMS.
> >
> > what about transactions that span data sources? yes, this
> > does happen.
>
> Yeah, it *seems* to happen, but it doesn't actually.  Any vendor who tells
> you he can do real transactions across data sources is a liar, or using a
> new and improved definition of transaction.  You can do it %99.99 of the
> time but that last %.01 is the bitch.
>
> With J2EE you get the complete illusion that you are doing txns across as
> many data sources on as many systems and vendors as you want, but behind
> the illusion there is the nonzero risk that the data is inconsistent.  In
> a real transactional system, you can never have inconsistent data.

This thread is suffering from a severe lack of technical information. Can
you go into more technical detail on what that 0.01% is (and is caused
by)?

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, Jeffrey W. Baker wrote:

> I haven't looked at AO or AxKit, but if I can untar either one of them and
> just get to work, that will rule.

You can't, but thats because I believe in the CPAN model - use pre-written
components. I don't believe shipping all those components in AxKit (and
there are a fair number required) is the right solution. Maybe I'm
mistaken.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, (Matthew Kennedy) wrote:

> > > Transaction support for your business logic is easy in J2EE. It's not
> > > clear how you do this in Perl?
> >
> > Use an RDBMS.
>
> You don't understand that it can have nothing to do with a RDBMS. I'm
> not talking about transaction control within the context of a database
> within a RDBMS. As I wrote to another user on this list, say you have
> two database servers and you need to implement a process which operates
> on each database in order. Maybe you move an item from on to the other.
> What if the second operation fails? Natually you want to roll-back to
> before the operation on the first. That's what J2EE transactions are
> about. See how RDMBS transactions are a different deal in this
> situation?

The problem with this analogy is that in Perl we'd just use exception
handling with automatic rollback on the databases in question (assuming
you don't commit). Throw an exception and be done with it.

You'd probably have to come up with a better scenario where J2EE
transaction management is really required. I've been struggling to grasp
the need for this concept since I attended a Microsoft developer day where
they demo'd their COM based transaction manager for the first time.

But then I'm an old style RDBMS guy. We built multi-million dollar Sybase
systems for large insurance companies. We never needed a transaction
manger. &shrug;

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Perl vs Java (XML Modules)

[Matt Sergeant]

On Tue, 5 Dec 2000, Drew Taylor wrote:

> I know this goes a little off topic, so I apologize in advance.

I changed the topic for you :-)

> One big sticking point with Perl I'm just starting to run into is XML.
> Yes, Perl has great XML modules, and many more promising ones. But where
> is the _validating_ XML parser? I'm doing some XML work where a
> validating parser would be very nice, speed hit or not. I can work
> around it easily (this is perl :-), but it would save me some work.

XML::Checker.
Also see www.perl.com which links to Kip Hampton's XML.com article about
validating using XPath.

> The XML & Java combination has a LOT more corporate resources (read $$$)
> focused on it than Perl & XML. How many Java-based XML software
> announcements have you seen lately? Now compare that to Perl-based XML
> modules. The numbers don't compare very well. What can we do about this?

Very little, except produce our own XML modules that can do our work. And
you can help by praising those that do produce good XML modules and by
using the modules that work rather than those that don't (hint: XML::XPath
vs XML::DOM with XML::XQL). Apart from validation, what are you missing?

> I can't help write a validating parser, but I would be happy to help
> test it out. IMHO, more XML support would help sell perl into more
> corporate settings. Java is big into buzzwords, and XML is one of the
> biggest there is at the moment. And as we know PHBs like buzzwords, so
> that is one more point in Java's favor.

Actually XML is one area where mod_perl kicks Java's butt in some ways.
AxKit is *faster* than Cocoon. Please test and see for yourself if you
don't believe me. And building XML based web sites with AxKit is *really*
easy. I built modperl.sergeant.org in 10 days of spare time, including a
content management system for the news articles (note that half of the CMS
code is just a plain mod_perl handler). I'll stick an article online
shortly about how the site is constructed.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, (Matthew Kennedy) wrote:

> > I guess what I'm getting at is that I hear a lot of marketing hype about
> > Java being a better "enterprise solution", but I'm curious as to what are
> > the purely technical reasons for using Java over Perl.  What exactly can
> > you do in Java that you can't do as easily in Perl?
>
> Transaction support for your business logic is easy in J2EE. It's not
> clear how you do this in Perl? By CORBA ORBs and TMs I suspect, but
> there's no real standard framework for that in Perl. There are other
> lesser advantages too... standardized XML support is one of them
> (topical for me right now).

XML support I think we have mostly covered now (or maybe you disagree?).

But I'd really love to hear some rational discussion on transaction object
support. There are open source J2EE implementations - would it be possible
to look a porting the transaction management components of that to Perl?
Would this be desirable? Personally I put all transaction critical stuff
in the database, and rely on RDBMS transaction support, but I've never
done J2EE, so I'm curious as to the advantages.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, Ajit Deshpande wrote:

> On Tue, Dec 05, 2000 at 08:26:35PM +0000, Matt Sergeant wrote:
> > > application should install itself -- .conf files, .htaccess files,
> > > dbm's, directory structures, perl code, html and templates, correct
> > > version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
> > > mod_ssl, mod_whatever, mysql, database schemas, database contents,
> > > DBI, Session, front-end proxy -- everything.  Each application should
> > > gronk whatever's already there, or rename it out of the way.
> > > Warnings in big letters.  Tough doots.
> >
> > Do you have any idea how hard this is? Seriously. Because I do. Dave
> > Rolsky does. And doing this for free is going to be nigh on impossible.
>
> IMHO, it shouldnt be that difficult if you make some good assumptions.
> For example, how difficult will it be to maintain the following package:
>
>1. Assume Perl 5.5.3 OR 5.6.0
>2. Assume latest Apache and static mod_perl
>3. Assume latest Apache::DBI, Apache::Session,
>4. Assume latest HTML::Mason (I cant speak for the others, yet)
>5. Assume latest MySQL
>
> Now, with the above, I think we can maintain a basic demo, templating
> system with session management using Apache::DBI fairly easily.

I can only suggest you try it as I speak from experience.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, brian moseley wrote:

> the availability of application server products in the java
> world is another example. go look at enhydra enterprise
> (http://www.enhydra.org/software/enhydraEnterprise/) and
> tell me that something like that exists in the perl world.

http://www.mediasurface.com

Sadly though, its only one product in a sea of Java products.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, Eric Strovink wrote:

> A number of people have been beating around this bush, so why not just
> mow it down?
>
> A huge win for advocacy would be a small set of complete example
> applications targetted at, say, the last two RedHat distros.  Each
> application should install itself -- .conf files, .htaccess files,
> dbm's, directory structures, perl code, html and templates, correct
> version of Perl, CPAN packages for any stuff needed, Apache, mod_perl,
> mod_ssl, mod_whatever, mysql, database schemas, database contents,
> DBI, Session, front-end proxy -- everything.  Each application should
> gronk whatever's already there, or rename it out of the way.
> Warnings in big letters.  Tough doots.

Do you have any idea how hard this is? Seriously. Because I do. Dave
Rolsky does. And doing this for free is going to be nigh on impossible.

> Each application package should contain dumbed-down documentation that
> explains what it does, and how it does it.

Good writers are really hard to come by.

I don't want to poo-poo on the idea by any means, the *idea* itself is
fine, but the implementation of it is non-trivial.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl advocacy project resurrection

[Matt Sergeant]

On Tue, 5 Dec 2000, Stas Bekman wrote:

> I see two main streams:
> 1) Online zines.
>
> I think that we should start working on locating ezines wanting to publish
> mod_perl related articles (preferrably for a fee, to give incentives for
> others to write)

While I can't offer any money for articles (unless someone out there wants
to sponsor the site!), hopefully if anyone has an itch to write about
something they'll go along to http://modperl.sergeant.org/contribute.xml
and drop us a note.

However I'd also really like to see more in offline publications. For
example, I've never read anything in Web Techniques, other than a Lincoln
or a Merlyn article, go into detail about mod_perl, or even just review
it, or review some system built on mod_perl (like Mason or Embperl for
example) [*]. I have, however, seen reviews of Velocigen, which often cite
mod_perl as a competitor and as difficult to install, and therefore bad
(note that I do think mod_perl is still a tad too hard to install for
complete newbies, but its a specious argument because you tend to only do
it once or twice, and thats something not many documents focus on).

[*] Actually this is a lie, I've seen an article about Mason in WT, but
I'd like to see more.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl Guide 2.0

[Matt Sergeant]

On Tue, 5 Dec 2000, Salve J Nilsen wrote:

> > 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
> > already working in the guide, other formats to come).
>
> I'd _very_much_ like a PDA-version of the guide! It might have to be
> set up differently (e.g. code snippets presented with fixed a width
> font should go into seperate files, and deep nesting of lists should
> be avoided (max. 2 levels?)). Lots of UI improvements could probably
> be made... :)
>
> The guide as it is, isn't much readable on my iPaq, at least. :(

What's the format the iPaq can read? Isn't it an XML format?

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: mod_perl Guide 2.0

[Matt Sergeant]

On Tue, 5 Dec 2000, Stas Bekman wrote:

> Since we have already started working on mod_perl-2.0, I wanted to get in
> early and provide the base for the one and only source of mod_perl
> documentation. These are the things that I see important:
>
> 1. *All* pods located under one roof. API, Installation, Configuration,
> Tips, Trick and more.

Is the guide the best place for tips and tricks? Its certainly the best
place for hard-core installation configuration and other stuff, but often
tips and tricks focus on one particular technology. Are we missing out on
having a place to store smaller tips and tricks (you know where I'm
thinking of keeping them...) ?

> 2. Automatic retrieval of pods sections from .pm files and integration in
> the documentation tree.

Is that really necessary? I assume you mean having the Apache.pm docs as
part of the guide, and the mod_perl*.pod files also?

> 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
> already working in the guide, other formats to come).

What other formats do you think people want/need?

> 4. Distribution within mod_perl or outside of it? (The main point of
> having documentation separated as it may be updated more often than
> software releases.) so this is arguable.

Yes, keep it out of mod_perl. We all love doug but he's slower than a very
slow thing on a Sunday :-)

> 5. Commit rights. Should be available for all mod_perl committers, one or
> more persons will be responsible for keeping the healthy layout of the
> documentation, review documentation commits. Pretty much making it a
> real community project and not Stas Bekman's project.

/me spies the ulterior motive behind that :-)

> 6. Mailing list (or reuse of cvs list) for corrections/contributions

Is there anything wrong with using this list for that?

> 7. The relevant parts from the current guide is to be merged into the new
> guide and eventually freezed as mod_perl-2.0 will become the main product,
> and mod_perl-1.x will be not supported anymore (I suppose a few years from
> now).

We probably need to keep two separate projects, going on what is known
about mod_perl 2.0 so far.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCE] New mod_perl Web Site!!!

[Matt Sergeant]

With a flash of fireworks and champagne I'd like to announce to the world
our new mod_perl news and advocacy web site:

http://modperl.sergeant.org/

We hope to be able to bring to you all the latest relevant perl news, and
articles about mod_perl development and other areas of interest, all in
once place. We also have a copy of the mod_perl guide on the site, broken
down into sections - we hope you like this format. Eventually we will
have all the mod_perl documentation from the source POD files, and allow 
users to add comments (much like you can with the PHP documentation), and
we have much more planned for the site.

The entire site is built using AxKit and a small mod_perl handler for   
uploading news articles.

We hope you like the design, although we are aware that there are a couple
of issues with it currently:

  - We don't have O'Reilly's permission to use the eagle logo, so will
probably have to do a bit of a re-design
  - We need to find a reasonably nice way to integrate advertising onto
the site.

If you have any article or news item you would like to see published on
the site, then please visit our contribute page on the site, or drop us a
line at [EMAIL PROTECTED]

Enjoy,

The modperl.sergeant.org editing team.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Apache::Dispatch directives

[Matt Sergeant]

... do not seem to be allowed in .htaccess files. I don't see a reason for
this restriction, Geoff ???

Particularly, I want to just be able to say:

DispatchPrefix MyModule

in a .htaccess file and have it just work.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Antwort: RFC: DBI::Prof

[Matt Sergeant]

On Fri, 1 Dec 2000, Tim Bunce wrote:

> On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote:
> >
> > It would be much easier for Tim to do it from the inside than any of us
> > doing the overloading hacking, but that's up to Tim to decide when if ever
> > this should go in :)
>
> Things are changing for the better workwise now and I hope to get back to
> regular DBI and DBD::Oracle (and Oracle::OCI) work early next year.

You said that at TPC :-)

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: Apache::Carp - Error Handling under mod_perl

[Matt Sergeant]

On Fri, 1 Dec 2000, Gunther Birznieks wrote:

> The other thing that worries me is that even if you sneak the code back
> into the PageKit hierarchy you are still not doing everything Lincoln is
> doing to help deal with eval issues. This is a particularly thorny problem
> (and I suspect part of the reason why Matt wants CGI::Carp to die ... no
> pun intended).

The reason I want it to die is that it doesn't deal with the eval issues.
It may try to. But it doesn't succeed.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: More Speed -> mod_perl Module for HTML Compression

[Matt Sergeant]

On Thu, 30 Nov 2000, Geoffrey Young wrote:

> > > just beware that not all browsers that claim to accept gzip
> > compression
> > > actually do...
> >
> > No its the other way around. Not all browsers that can accept
> > gzip send
> > out Accept-Encoding: gzip. Notably early versions of IE4.
>
> I was basing that on discussions on the mod_gzip list and the following
> (from the mod_gzip code)
>
>  * 5. Many browsers ( such as Netscape 4.75 for UNIX ) are unable
>  *to handle Content-encoding only for specific kinds of HTML
>  *transactions such as Style Sheets even though the browser
>  *says it is HTTP 1.1 compliant and is suppying the standard
>  *'Accept-encoding: gzip' field. According to the IETF
>  *specifications any user-agent that says it can accept
>  *encodings should be able to do so for all types of HTML
>  *transactions but this is simply not the current reality.
>  *Some will, some won't... even if they say they can.
>
> I don't have any first hand experience with it, though...

Yikes, thats really dumb. I guess its both ways around then...


So really your best bet is to just use AxKit, which will compress just
your HTML content and won't handle your CSS files or anything else :-)


-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: More Speed -> mod_perl Module for HTML Compression

[Matt Sergeant]

On Thu, 30 Nov 2000, Geoffrey Young wrote:

> there's mod_gzip, available from
> http://www.remotecommunications.com/apache/mod_gzip/
> which I've played with and looks pretty good
>
> or Apache::Compress, available from CPAN, which also works rather nicely
> (and is Apache::Filter ready, so you can chain PerlHandlers into it)
>
> just beware that not all browsers that claim to accept gzip compression
> actually do...

No its the other way around. Not all browsers that can accept gzip send
out Accept-Encoding: gzip. Notably early versions of IE4.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: More Speed -> mod_perl Module for HTML Compression

[Matt Sergeant]

On Thu, 30 Nov 2000, Nigel Hamilton wrote:

> Hi,
>   I'm trying to reduce the amount of data sent from server to
> browser by using compression ---> hopefully accelerating the time to
> serve a page.
>
>   Does anyone know of a mod_perl module that compresses HTML and a
> companion Javascript procedure that decompresses the data on the
> client-side?
>
>   I know there are Gzip modules that zip files on the way back to
> the browser ... but I'm after something that zips on the server and
> decompresses transparently in Javascript across all browsers. Ideally I
> want to do: document.write(uncompressed-contents) in Javascript on the
> client-side.
>
>   Has anyone come up with something for this?

Nobody here would be mad enough to do this... Is it on an intranet? If
not, you'll never get me visiting your site - I don't enable javascript
generally.

>   Also for average-sized files, does the time taken to perform the
> decompression/compression negate any speed increase gained by reduced file
> size?

I don't think so, but it probably depends a huge amount on the size of
your pipe and how many pages you're hoping to server. For example, I'm on
a 64K pipe, so CPU isn't the limiting factor of what I can serve - the
pipe is. So I gzip and can serve more pages.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: Apache::Carp - Error Handling under mod_perl

[Matt Sergeant]

On Thu, 30 Nov 2000, Gunther Birznieks wrote:

> Can you help by explaining what this does that is different from CGI::Carp?
> What are you doing that is Apache specific? Could CGI::Carp do the job? If
> there was something you needed added to CGI::Carp, would it make sense for
> you to add the apache-specific function flag to CGI::Carp instead of making
> a brand-new module?

Can we not burn CGI::Carp yet? :-)

I'm assuming this new module is also based on $SIG{__DIE__}... in which
case, shoot me now.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WebDAV support in mod_perl

[Matt Sergeant]

On Wed, 29 Nov 2000, Ian Kallen wrote:

>
> Yes, I've contemplated either:
>
> 1) implementing the DAV protocols entirely in Perl for mod_perl
> 2) gluing in XS into mod_dav -- IIRC mod_dav has hooks for non-filesystem
> respositories; it'd be great just to expose that API to mod_perl (haven't
> cracked open that code yet though)
>
> Issues: what will be required to implement DeltaV (I need concurrent
> checkouts and versioning) as well?

Depends what you base it on. CVS or subversion or something? Greg Stein
was saying that DeltaV isn't finalised anyway, so you'd be writing clients
too!

> What's up with the expat-lite
> in Apache conflicting with XML::Parser's expat?

Just compile Apache with RULE_EXPAT=no, and if you want to compile mod_dav
with the shared expat on expat.sourceforge.net then use the patches in
http://axkit.org/download/

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Apache::SSI design questions

[Matt Sergeant]

On Wed, 29 Nov 2000, Bill Moseley wrote:

> At 11:47 PM 11/28/00 -0600, Ken Williams wrote:
> >1) Is it preferred to use POSIX::strftime() for time formatting, or
> >   Date::Format::strftime()?  One solution would be to dynamically load one
> >   or the other module according to which one is available, but I'd rather
> >   not do that.
>
> Hi Ken,
>
> Why not Apache::Util::ht_time()?

Or if you need to run outside of mod_perl, Time::Object::strftime (which
doesn't load all of POSIX.pm, but is done in XS, so is faster/lighter than
Date::Format).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: segmentation fault when using custom config module

[Matt Sergeant]

On Wed, 29 Nov 2000, Dave Rolsky wrote:

>   my $cfg = Apache::ModuleConfig->get($r);

Try:

my $cfg = Apache::ModuleConfig->get($r, __PACKAGE__);

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: DBI::Prof

[Matt Sergeant]

On Wed, 29 Nov 2000, Fabrice Scemama wrote:

> It would be nice if Tim Bunce simply added it as a parameter
> to DBI's existing methods. Why not ask him?

I think most people would prefer to see it as a separate module. Generally
people do their query optimisations outside of DBI (and Perl), using the
database's in-built profilers.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RFC: DBI::Prof

[Matt Sergeant]

On Tue, 28 Nov 2000, Stas Bekman wrote:

> Or is there any reason for not using DBI::?

Tim mandates it. DBI:: is reserved for DBI only. DBD::* is reserved for
DBD drivers only, anything else goes in DBIx.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [OT] Mixing C and HTML code just like in ePerl?

[Matt Sergeant]

On Tue, 28 Nov 2000, Vladislav Safronov wrote:

> Hi,
> 
> I use ePerl and it's good, but some things need better performance.
> Is there any "chtml" compiler that allow me freely mix C and html code
> just like in ePerl:
> 
> 
> HTML code
> <%
>  C code ..
> %>
> HTML code
> <%=(C expr.)%>

Inline.pm

But if ePerl is slow then its probably not compiling the script to
Perl. Try something like embperl, or one of the many other solutions.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Does mod_perl have anything to do with KeepAlive?

[Matt Sergeant]

On Tue, 28 Nov 2000, Larry Leszczynski wrote:

> Suppose front-end server A is handling user requests.  In the process of
> handling a front-end request, suppose I use LWP or equivalent to make a
> HTTP request from A to a back-end server B to get some data that is
> needed.  Assuming all the right headers are set for KeepAlive to work
> (content length, etc.), can the connection between A and B even take
> advantage of KeepAlive for the next time A makes the same request to B?

If you use HTTP::GHTTP, and keep the same request object around in server
memory, you can set the appropriate keepalive headers, and it should
re-use the same connection next time around assuming the keepalive hasn't
timed out.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Need content editors

[Matt Sergeant]

I'm in need of a couple of volunteers for editing content for a new
modperl advocacy site. This will involve finding and adding new content to
a site dedicated to advocating modperl, and also editing existing content
and helping develop the site further.

I really only need a couple of other people, so please only respond if you
have about 1/2 an hour each day you can dedicate to the site, and
knowledge of mod_perl and XML would be a definite bonus, though you will
learn AxKit and XML in the process if you don't already.

Contact me directly if you're interested.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: i am looking for mod perl tutor

[Matt Sergeant]

On Wed, 22 Nov 2000, mohammed abdul bari wrote:

> Hi,
> I am looking for mod perl tutors. I have a pretty good knowledge of perl but 
> just a lil bit about appache modules. I need some one who could spare a day 
> or 2 with 1 or 2 hours a day to get me basics. I live in santa clara.

Sounds like you want to attend a conference. See http://www.apachecon.com/

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: i need reload the scripts

[Matt Sergeant]

On Wed, 22 Nov 2000, bari wrote:

> i have some modules already written in my subdirectory and i have made
> chages to them an i need to reload them. how do i reload the perl scripts
> using mod perl. i was going through documentation it asked me to use
> PerlModule Apache::StatINC
> PerlInitHandler Apache::StatINC
> 
> but i am not clear with this. where do i have to add this. i am new to mod
> perl. can any one help me figure out this.

Use Apache::Reload (or StatINC if you want less flexibility). Install it,
read the documentation, and you're set.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] HTTP::GHTTP

[Matt Sergeant]

On Wed, 22 Nov 2000, clayton cottingham wrote:

> man that is one crazy module!
> 
> in under ten minutes i had the thing running!
> 
> kudos again to you matt!

I'd be happy if it wasn't turning out to be more popular than
AxKit! *sigh* :-)

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] HTTP::GHTTP

[Matt Sergeant]

On Wed, 22 Nov 2000, Mark Doyle wrote:

> 
> On Tuesday, November 21, 2000, at 06:28 PM, Matt Sergeant wrote:
> 
> > HTTP::GHTTP is a lightweight HTTP client library based on the gnome 
> > libghttp library. It offers a pretty simple to use API for doing HTTP 
> > requests. This can be useful under mod_perl because the alternatives 
> > (e.g. LWP) are quite large. 
> 
> Will the ghttp library work under Solaris and, if so, where can it be downloaded?

It should work pretty much anywhere (probably even windows if you can get
past the configure stage). Its part of the gnome project, so you can get
it from http://www.gnome.org/. Or a search should turn up a solaris
package for it.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ libapreq ] desesperatly need of .32 or .33

[Matt Sergeant]

On Wed, 22 Nov 2000, Thierry-Michel Barral wrote:

> Hi everyone,
> 
> I'm using Apache::Request, and I've encountered a bug !
> [
> I've done a POST multiform data, and the first field, a textarea, could contains at 
>the end some garbage. Garbage because data is changing.
> ]
> 
> I'm quite sure [ after a quick glance at mod_perl ML archive] one of the patches 
>proposed could solve the problem.
> 
> So I need desesperatly a new version of libapreq, the .32, or .33 if it's finished !
> 
> I do not know if Doug still maintains it, or if it's someone else.
> 
> But please, could it be possible to see very very soon a new release ?

Doug mentioned to me at ApacheCon (or it may have been back at TPC) that
he would like someone else to take over maintainence of
Apache::Request. If nobody volunteers, I'm willing to look at doing so,
although I've only just started that long road into using XS, so I'm more
likely to spend time applying patches than writing them.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] HTTP::GHTTP

[Matt Sergeant]

On Tue, 21 Nov 2000, Perrin Harkins wrote:

> On Tue, 21 Nov 2000, Matt Sergeant wrote:
> > HTTP::GHTTP is a lightweight HTTP client library based on the gnome
> > libghttp library. It offers a pretty simple to use API for doing HTTP
> > requests. This can be useful under mod_perl because the alternatives
> > (e.g. LWP) are quite large.
> 
> Any idea how it compares to HTTP::Lite in size and speed?  Can it do SSL?

See my other mail regarding speed. I don't think it can do SSL, but its
dependant on libghttp, so when it can do SSL (which I would expect it
should be able to at some point in the near future given the patent
expiration on RSA), so will HTTP::GHTTP.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [ANNOUNCE] HTTP::GHTTP

[Matt Sergeant]

On Tue, 21 Nov 2000, Matt Sergeant wrote:

> This is a bit off topic as its not specifically mod_perl, but I wrote it
> for use in a mod_perl environment, so I figure it will be useful to other
> people.
> 
> HTTP::GHTTP is a lightweight HTTP client library based on the gnome
> libghttp library. It offers a pretty simple to use API for doing HTTP
> requests. This can be useful under mod_perl because the alternatives
> (e.g. LWP) are quite large.

I should clarify this... LWP::UserAgent loads about 110K of Perl code (*).
And Perl code compiles to more memory than the pure text form of Perl (I
haven't tested exactly how much memory it uses though). HTTP::Lite loads
about 71K of Perl code (which surprised me!). HTTP::GHTTP loads about 24K
of Perl code (note that GHTTP.pm is only 746 bytes of actual Perl, so most
of that 24K is the same 24K as loaded by the other 2 modules, Exporter,
AutoLoader, Dynaloader, strict, etc, so these will be loaded into your
mod_perl anyway). HTTP/GHTTP.so is about 14K stripped on my Linux box. So
even unshared its not going to have a big impact on your servers. And
GHTTP does all its work in C - the only thing in Perl is the constructor.

(*) using: perl -M -e 'print join("\n", values %INC)' | xargs cat
| /tmp/nopod | wc

(where nopod strips out all pod)

Now as for performance. Its a killer:

Benchmark: timing 1000 iterations of ghttp, lite...
 ghttp:  7 wallclock secs ( 0.79 usr +  0.79 sys =  1.58 CPU)
  lite: 21 wallclock secs ( 6.86 usr +  2.83 sys =  9.69 CPU)

(I had to fix a bug in the code, so I'll put a new one on CPAN tomorrow -
its always fun how often running benchmarks reveal bugs!)

Let me know if you want the benchmark source code.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANNOUNCE] HTTP::GHTTP

[Matt Sergeant]

This is a bit off topic as its not specifically mod_perl, but I wrote it
for use in a mod_perl environment, so I figure it will be useful to other
people.

HTTP::GHTTP is a lightweight HTTP client library based on the gnome
libghttp library. It offers a pretty simple to use API for doing HTTP
requests. This can be useful under mod_perl because the alternatives
(e.g. LWP) are quite large.

Example usage:

# short get() method
use HTTP::GHTTP 'get';
print get("http://axkit.org/");

# longer OO usage
my $r = HTTP::GHTTP->new();
$r->set_uri("http://xml.com");
$r->process_request;
print $r->get_body;

Supports proxies and authentication too. Heading to CPAN now.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: moidperl, OOP & DBI

[Matt Sergeant]

On Tue, 21 Nov 2000, Ilya Soldatkin wrote:

> I  am creating an object that make queries to database. But how shall I
> explain to him what database handler he shall use?
> Under mod_perl it is too dangerous to make $dbh global variable.
> Well, I can create data field in this object that will store current $dbh,
> but it seems too strange too me to have such data field in object:
> 
> $person={
> name=>'Jack',
> age=10,
> ...,
> $dbh=>...
> }
> 
> $dbh have no relation to information about Jack.
> Is there any better solution?

This really has little to do with mod_perl, more about object design. You
should get yourself a book about OO design. Or you can use a Singleton
(see Class::Singleton on CPAN, or write your own Singleton module - its
only about 10 lines of code).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Probably [OT] Are there any Simple Generic Server modules

[Matt Sergeant]

On Mon, 20 Nov 2000, Greg Cope wrote:

> Dear All
> 
> This is a little OT - but bear with me.
> 
> I am looking for a simple generic server (prefably OO) that I can use
> for my NON OO stuff.
> 
> I have writen my own, but I am after ideas 
> 
> One project I've got involves getting HTML (template)files via LWP, and
> uploads them into an IPC cache for HTML::Template.  It needs to accept
> signals so that Apache can HUP it to go get new templates.
> 
> Using a generic server class can enable me to get the code out of
> apache.

I use POE for this. It allows me to have one server and add different
modules for it, including things like an IRC bot, and a TCP/IP
listener. All in the same POE kernel.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Inline.pm

[Matt Sergeant]

On Tue, 14 Nov 2000, Geoffrey Young wrote:

> > Inline.pm!
> 
> you have any experience with this?  I forget where I read the article (TPJ?)
> but it looks really cool...

Actually only a bad experience - I tried to get some sort of wrapper for
libghttp working with Inline, but couldn't. However for things that don't
need external libraries I think it is probably a great way to go. And a
much better introduction to the internals than straight XS.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: [ANNOUNCE] ApacheCon USA 2001: Call For Papers

[Matt Sergeant]

On Tue, 14 Nov 2000, Greg Cope wrote:

> > I'd like to see a talk on templating systems and mod_perl. Hint to whomever
> > is watching. :)
> 
> Your trying to reignight that old thread  don the flame proff stuff,
> seriously this would be a good mod_perl thing.
> 
> Matt are you going to do something on AXKit ?

Assuming my proposal gets accepted, yes. Although I think next time I'm
going to be less nice about Cocoon :-)

> 
> If any one is interested I could do something on Session Manager - which
> I've been looking at rewriting in C - but I have to learn C at the same
> time so its very slow 
> 

Inline.pm!

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Fast DB access

[Matt Sergeant]

On Thu, 9 Nov 2000, Ask Bjoern Hansen wrote:

> On Wed, 11 Oct 2000, Matt Sergeant wrote:
> 
> > > > Most modern DBMS software should be able to handle 50 queries per second
> > > > on decent hardware, provided the conditions are right. You're not going to
> > > > get anything better with flat files.
> > > 
> > > Hmm... I guess it all depends on what your queries look like, but you can
> > > get better results from flat files if you put them in a percise layout. 
> > > Granted if you are talking about having a million lines in a single
> > > flat file, then I definately agree with you.
> > 
> > I think the limiting factors are quite a bit sooner than a million
> > lines. What I'm trying to get across is that developers should be
> > focussing on letting the DBMS do what a DBMS does best - queries. The DB
> > is far better placed (and generally better developed) to do the
> > optimisation than trying to come up with a flat file strategy that works
> > with your system.
> 
> If you're always looking stuff up on simple ID numbers and
> "stuff" is a very simple data structure, then I doubt any DBMS can
> beat 
> 
>  open D, "/data/1/12/123456" or ...
> 
> from a fast local filesystem.

Note that Theo Schlossnagel was saying over lunch at ApacheCon that if
your filename has more than 8 characters on Linux (ext2fs) it skips from a
hashed algorithm to a linear algorithm (or something to that affect). So
go careful there. I don't have more details or a URL for any information
on this though.

FWIW, I need to fix this in AxKit, since it uses MD5 hex hashes as
filenames...

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: HTTP Mod_Perl mini-server

[Matt Sergeant]

On Fri, 3 Nov 2000, Nigel Hamilton wrote:

> Hi,
> 
> I'm contracting for an Ad Serving company and we were mooting the idea of
> writing our own lean and mean web server for serving the Ads.
> 
> We would like to hold all the Ads in memory (each Ad is less than 20K).
> 
> The next thing is to create a pool of mod_perl-esque processes that will
> handle the AD requests and also hold persistent connections to the
> database.
> 
> I would like to write this mini-server in perl ... but maybe a threaded
> programming language is better?
> 
> Does anyone know a good process/threading model for handling the requests
> and passing them around? Will we see a significant performance improvement
> in any event?

egads, don't do it... Web servers are well developed for this kind of
thing, and modern filesystems (e.g. ext2fs) will buffer the ads in RAM
anyway if you have enough. You're not likely to get any speed increase
doing it this way. If you're that concerned about perhaps the weight of
Apache + mod_perl, consider trying TUX or thttpd, or something else
lightweight written in C.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: dynamic vs. mostly static data

[Matt Sergeant]

On Thu, 2 Nov 2000, Neil Conway wrote:

> I'm writing a web app in mod_perl, using a PostgreSQL database
> backend and HTML::Template. In looking for ways to optimize
> performance, I noticed that although my code is doing several
> (say, 4-5) database queries per handler/webpage, a large part
> of the data (~2 queries) is mostly static (it will change
> perhaps once per week, or once per month). It's obviously
> inefficient to run these queries on the database for every
> single request.
> 
> How can I 'cache' this data so that all Apache children can
> access it quickly? Is there a way to automatically update
> this cache periodically (say every 10 minutes)? Also, this
> solution should work on any reasonably modern UNIX system
> (Win32 is not important for now).

Along with all the other fine suggestions here, you might like to check
out the Memoize module on CPAN. I don't think it yet offers a way to
invalidate the cache, but I know that is planned.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Seg Fault Issues- mod_perl and XML::Parser

[Matt Sergeant]

On Thu, 2 Nov 2000, Tom Harper wrote:

> Hi--
> 
> In case anyone encounters the same segv issues,
> recompiled apache with mod_perl 1.24--
> 
> explicitly set Rule EXPAT=no rather than 
> Rule EXPAT=default in the apache_base/src/Configure.  
> 
> No more segv.
> 
> Then i recompiled again with mod_perl 1.23.  
> 
> Again, no more segv.
> 
> Go figure.

I'm sure that's almost exactly what the axkit faq tells you to do :-)

The problem is that the expat isn't in mod_dav, its in Apache, so even if
you don't have mod_dav installed, Apache compiles in expat. If at a later
date you feel you need mod_dav you can use the patches in the axkit
download directory.

> Anyhow, based on this experience we are very enthusiastic
> about XML::Parser package.  We are mis-using XML::Parser 
> as part of a X(HT)ML based templating engine, and since the
> fix it has handled significant load without complaint
> (>50 concurrent connections).

Just a word of warning: XML::Parser is slower than you think. All the
method calls, back and forth from C to Perl, and having one of those for
every node in the XML document, is all very slow. Cache what you can,
whenever you can, or your platform won't scale very well. (speaking from
direct personal experience).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: zlib error?

[Matt Sergeant]

On Thu, 2 Nov 2000, Homsher, Dave V. wrote:

> Hi all,
> 
> I came in this morning to find my server (semi) down with the following
> error message in the logs:
> 
> [error] Out of memory during "large" request for 135168 bytes at
> /opt/perl5/lib/site_perl/5.6.0/PA-RISC2.0/Compress/Zlib.pm line 198
> 
> This is on an HP-UX machine with several _gigs_ of memory. In my mod_perl
> modules, I compress my cookies (using Compress::Zlib) before sending them
> across to the browser. All of the mods that generate cookies were getting an
> internal server error :/
> 
> I did apachectl graceful with no luck, then apachectl restart with no luck
> again, and finally a stop and start fixed the problem, but for how long?
> 
> Has anyone seen this or know where to start looking? It appears to be some
> sort of memory leak, but where to begin looking?

See my previous posts to this list regarding finding memory leaks in
AxKit. The techniques I used should help you, I hope.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Putting together the TPC mod_perl track

[Matt Sergeant]

On Wed, 1 Nov 2000, Sander van Zoest wrote:

> On Wed, 1 Nov 2000, Nathan Torkington wrote:
> 
> >  * Case studies showing how big companies use mod_perl
> > This latter is an important part of the Perl conference.  Many
> > companies who would never 'fess up to using Perl seem quite happy
> > to send employees to speak at conferences.  Their talks end up as
> > a big advertisement for Perl, and lets us name-drop the company as
> > a Perl user.  I see no reason why the same shouldn't happen with
> > mod_perl.
> 
> At the last US ApacheCon I did a talk on how we do XML/modperl related
> stuff for our publishing model at MP3.com, Inc. I have since then changed
> companies, so I can't really talk about that anymore (still got slides
> on my personal site though).
> 
> The only thing I can really talk about is my current experiences 
> in regards to i18n with the mailing list archives at 
> , but that would be pretty boring 
> I would think.

You could talk about how Cocoon couldn't handle the load so you installed
AxKit :-)

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Putting together the TPC mod_perl track

[Matt Sergeant]

On Wed, 1 Nov 2000, Marc Spitzer wrote:

> what is AO?

A port of the servlets architecture to mod_perl.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Seg Fault Issues- mod_perl and XML::Parser

[Matt Sergeant]

On Wed, 1 Nov 2000, Tom Harper wrote:

> Hi--
> 
> Having a problem with modperl/xml-parser.

Aren't we all :-)

Try http://axkit.org/faq.xml

Also, there is a patch for this (finally!) in http://axkit.org/download/ -
the mod_dav-shared-expat patch. I've sent this to Greg Stein (but not
heard any response yet).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: return from nested functions

[Matt Sergeant]

On Wed, 1 Nov 2000, Paul J. Lucas wrote:

>   If I'm a few levels deep into function calls, I'd liek to be
>   able to do something like "return SERVER_ERROR" and have the
>   entire call stack unwind and the current request stopped.
> 
>   Is there any way to do that?

Definitely use exceptions. I prefer Error.pm for this (sorry, Dave!),
which allows your handler to simply be:

sub handler {
return try {
...
} catch Exception::RetCode with {
my $E = shift;
return $E->{code};
} 
;
}

And then anywhere within your code you can go:

throw Exception::RetCode ( code => SERVER_ERROR );

Of course there's a bit of setup to do beyond that, which I intend to
rewrite the section of the guide to detail real soon now (tm).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Putting together the TPC mod_perl track

[Matt Sergeant]

Stas et al,

Since its getting towards the end of the year, should we be thinking of
putting together a mod_perl track for TPC?

Has anyone got any ideas on what they'd like to either a) talk about, or
b) hear talks about ?

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

ApacheCon presentation available

[Matt Sergeant]

http://axkit.org/docs/presentations/apachecon2k.sdd

The presentation is in Star Office (open office) format.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

RE: maximum (practical) size of $r->notes

[Matt Sergeant]

On Mon, 30 Oct 2000, Geoffrey Young wrote:

> that is my understanding... I guess that my point was that if you are going
> to have the data in perl somewhere the memory is going to be taken (for
> example, putting it in a tempfile but then local $/ and slurp).  pnotes
> allows for passing by reference, so it really doesn't matter when you read
> it in and where you use it, you still only have one copy...

Of course there's no functional difference between using pnotes and
something like:

$Apache::Pnotes::myvar = \$string;

Its really just syntactic sugar to make you think that its a notes table
for a perl data structure.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: maximum (practical) size of $r->notes

[Matt Sergeant]

On Mon, 30 Oct 2000, Todd Finney wrote:

> I'm concerned about putting large amounts of data into 
> $r->notes.  Some of our script output can be pretty 
> heavy.  If $r->notes can only take simple strings, how 
> large of a simple string is it safe to put in it?  Is there 
> a better way to do this?

AxKit uses the notes table to store interim strings for template
processing. I've not yet heard a bug related to it, but then I'm not
delivering massive files. I'd imagine it would probably be limited by
available memory.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Apache::GzipChain

[Matt Sergeant]

On Sat, 28 Oct 2000, Jerrad Pierce wrote:

> Is anybody using GzipChain?

Not in itself, but I'm using AxKit which also does gzip compression.

> Is there some known means of verifying that it is in fact working properly?

Yes, use:

lwp-request -H 'Accept-Encoding: gzip' -e -d 

Or ommit the -d and check for gobbledegook. But it tends to stuff up your
terminal :-)

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Connection Pooling / TP Monitor

[Matt Sergeant]

On Sat, 28 Oct 2000, Les Mikesell wrote:

> Is there any way to tie proxy requests mapped by mod_rewrite to
> a balanced set of servers through mod_backhand (or anything
> similar)?Also, can mod_backhand (or any alternative) work
> with non-apache back end servers?I'm really looking for a way
> to let mod_rewrite do the first cut at deciding where (or whether)
> to send a request, but then be able to send to a load balanced, fail
> over set, preferably without having to interpose another physical
> proxy.

>From what I could make out, I think you should be able to use backhand
only within certain  sections, and therefore have a request come
in outside of that, rewrite it to a backhand enabled location and have
backhand do its thing. Should work, but you'd have to try it.

Alternatively write your own decision module for backhand. There's even a
mod_perl module to do so (although apparently it needs patching for the
latest version of mod_backhand).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ApacheCon report

[Matt Sergeant]

On Sat, 28 Oct 2000, Greg Cope wrote:

> Matt Sergeant wrote:
> > 
> > http://modperl.sergeant.org/ApacheConRep.txt
> > 
> > Enjoy.
> 
> Thanks for that Matt, I did enjoy it - IBM's party coninciding with Suns
> keynote made me chukle ;-)
> 
> I eventually could not make the conferance due to a nasty deadline 
> 
> Did Doug mention when mod_perl 2.0 would / maybe / migh possibly be
> ready (I know, I know that it will be ready when its ready, only
> asking!)

Unfortunately I had to run (I had a beer with my name on it) before
getting chance to speak to Doug again. But it also depends a *lot* on the
progress of Apache 2.0, which is really holding mod_perl 2.0 up, from what
I can tell. But once that's out of the way, I don't think anything is
stopping mod_perl 2.0 progress - Doug seems to be able to move pretty
quickly on things, as he has a good idea where he's going with the
project.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: how to really bang on a script?

[Matt Sergeant]

On Sat, 28 Oct 2000, Christopher L. Everett wrote:

> So, I apologize for not describing my problem clearly in the first 
> place.  And again, my questions are:  How would I go about proving to 
> myself that my script does what I designed it to do?  Has anyone else 
> dealt with a similar problem, and how did they go about doing it?  If 
> I solve it for myself, would anyone else find the solution useful, and 
> how would I make it more useful to them?

Basically you've got exactly the right idea, and it *has* been done before
- I recall vaguely in the back of my head someone mentioning doing almost
exactly the same thing (changing server logs into a benchmark tool) at
ApacheCon, only I can't for the life of me remember who it was.

On the plus side though, provided you've got no POST parameters, its a
pretty trivial script. The hard part is getting a scalable engine to
execute all those requests. Really you have to do that in C I think - and
you should probably just look towards the source of ab.

FWIW, I think it was Theo Schlossnagel (mod_backhand guy) talking about
the utility, in fact I'm almost certain. Why don't you drop him a line.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

RE: ApacheCon report

[Matt Sergeant]

On Fri, 27 Oct 2000, Geoffrey Young wrote:

> I was really impressed with backhand at Theo's presentation at ApacheCon US
> in March.  From what I rememeber though, it had serious limitations in the
> SSL space.  Did Theo touch on that?  The converstation I had with him about
> it back then was that it was going to be addressed in a future release...

Yes he did touch on that, but I wasn't really understanding what he was
saying. I think it was that the frontend server is SSL enabled only, and
so the backend servers don't get the SSL cert. But he said you could use a
module to put the cert in a header, or something like that, and it would
work fine so long as you programmed it all right :-)

But then I know very little about SSL, and maybe got the wrong idea.

> also IIRC, backhand was only terribly useful behind something like BigIP
> (which is what we use).  Is there another implementation sheme now?

No that's right. Its the difference between high availability
(which BigIP *can* do) and load balancing (which backhand does).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ApacheCon report

[Matt Sergeant]

On Fri, 27 Oct 2000, Tim Sweetman wrote:

> In no particular order, and splitting hairs some of the time...
> 
> Sounded like mod_backhand was best used NOT in the same Apache as a phat
> application server (eg. mod_perl), because you don't want memory-heavy
> processes sitting waiting for responses. You'd be better off with a
> separate switching machine - or serve your static content from
> machine(s) that know to backhand dynamic requests to a phat machine. I
> think that's what Theo reckoned...

Yes, but the backend mod_perl servers are running backhand. So you have:

B  B  B  B
 \ |  | /
  \ \/ /
   \|/
F

Where all the servers are running mod_backhand, but only F is publically
accessible. There may also be >1 F. Its in his slides, and is prettier
than the above :-)

> "make simple things easy, and hard things possible" -
> What concerns me about systems like AxKit & Cocoon is that they may make
> simple things complex, and some hard things possible. But this is a
> naive comment not based on trying to build rilly big systems with them.
> Perl, maybe, doesn't make simple things anything like as easy as PHP.
> (Again, a naive comment that may be incorrect)

No, its correct, I think. I'd like to maybe next time do the second half
of the AxKit stuff as a Demo, but that takes some demo-able material thats
actually going to make you say "Ooh, that *is* easier than what I'm using
right now". So I'll work on it :-)

> Douglas Adams, who spoke at ApacheCon, previously made an interesting
> BBC documentary on hypermedia & its possibilities, in about 1992. Ted
> Nelson, I think it was, realised that the ability to _include stuff from
> other sources in your documents_ was important, and called it a
> "transclusion" (though that concept, IIRC, may have included the
> propagation of nanopayments to the source - not sure).
> 
> And at Apachecon, the XML guys say: "This Document() function's really
> cool! You can build a portal very easily..." And after falling asleep
> (reflex on hearing /portal/, marketing allergy) I thought, it's
> syndication/transclusion again. Evidently, a big idea. But a big idea
> buried in a heap of other big ideas.

Its all been done before. I spoke a bit to Rael Dornfest about P2P (Rael
is an O'Reilly guy behind the P2P summit). Basically its all the same
stuff we've already been doing, but its just a buzzword. But it often
takes buzzwords to make the world sit up and take notice and focus on the
right thing to be doing, even though they may not know it themselves!

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Connection Pooling / TP Monitor

[Matt Sergeant]

On Fri, 27 Oct 2000, Jeff Horn wrote:

> The only way I really see this working is in a threading environment.  First
> of all, for some databases database connections don't survive forking
> (Oracle is the notable example here).  Also, even if we could get forking to
> work, we would still get the scaling problem we are trying to avoid.
> Instead of Oracle keeping a huge list of persistent connections, the
> Connection Pool would keep a huge list of persistent connections.  In both
> cases each connection would map to a Unix process and all these processes
> would chew up OS resources big time!

I don't think thats a 100% fair analysis. First off, forking doesn't use
any more RAM than threading until you start copying data. And I don't see
that much of a scaling issue - we'd have a pool of connections available,
each as a child. Since you could control the number of connections
produced you wouldn't have to worry about the scalability issues too much
- the problems with things like mod_perl are that there is one connection
per child, regardless of what that child is doing. A pool would allow you
to make that a lot cleaner, and less resource intensive. At least I think
so... Unfortunately I don't have a need for this right now, so I'm not
willing to put the hacking tuits into it. Sorry :-(

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

ApacheCon report

[Matt Sergeant]

http://modperl.sergeant.org/ApacheConRep.txt

Enjoy.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Connection Pooling / TP Monitor

[Matt Sergeant]

On 27 Oct 2000, (Randal L. Schwartz) wrote:

> > "Tim" == Tim Bunce <[EMAIL PROTECTED]> writes:
> 
> Tim> You could have a set of apache servers that are 'pure' DBI proxy
> Tim> servers.  That is, they POST requests containing SQL (for
> Tim> prepare_cached) plus bind parameter values and return responses
> Tim> containing the results.
> 
> Tim> Basically I'm proposing that apache be used as an alternative
> Tim> framework for DBI::ProxyServer. Almost all the marshaling code
> Tim> and higher level logic is already in DBI::ProxyServer and
> Tim> DBD::Proxy. Shouldn't be too hard to do and you'd gain in all
> Tim> sorts of ways.
> 
> You could also use SOAP or SOAP::Lite as the interface.  Most of that
> code seems ready for this kind of application already.

There are some issues still with this architecture, the primary one is
that SOAP is too heavy weight for anything that seriously needs connection
pooling for speed issues, especially in Perl (due to the XML parsing speed
issues).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

RE: An idea, for comments

[Matt Sergeant]

On Fri, 27 Oct 2000, Geoffrey Young wrote:

>   - made mod_perl 1.2401 required due to DIR_MERGE memory leak in 1.24

Thats a pretty stern requirement at least until 1.25 is released. Perhaps
you could do what I intend to do with AxKit - do a regex which renames
DIR_MERGE to DISABLED_DIR_MERGE when running under 1.24 (needs to be done
physically in the file when you run Makefile.PL otherwise it will crash).

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Connection Pooling / TP Monitor

[Matt Sergeant]

On Fri, 27 Oct 2000, Tim Bunce wrote:

> > Sounds like just a CORBA/RPC type thing. Wouldn't you be better off using
> > CORBA::ORBit?
> 
> Maybe. I dunno. I don't actually need this stuff, I just want there to
> be a solution out there for those that do. I'm waving my hands around
> and pointing in various directions hoping someone will _do_ something!

Hehe...

OK, lets think about exactly what is needed here then. I figure Doug's
Apache::DBIPool module (for mod_perl 2.0) is exactly the right
architecture:

2 pools of connections (Busy and Waiting)
New connections always taken from the head of Waiting
Finished connections always replaced on the head of Waiting
Threaded architecture (DBI::Oracle handles don't survive a fork)
One thread for management
One thread per connection once a handle has been supplied
Some sort of timeout mechanism for connections if the pool is
fully allocated

Anything I've missed?

If we don't go the threaded route, we can't easily expand and contract the
connection pool I don't think - but I'd love to be proved wrong. Also an
entire Apache server for the connection pool would be too much - the
pre-forking server from the cookbook would be better. And it should even
work on Win32 now...

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: An idea, for comments

[Matt Sergeant]

You want Apache::Dispatch. It's almost exactly what you are looking for
(and it really rocks, IMHO).

On Fri, 27 Oct 2000, Nouguier wrote:

> Hi all
> 
> Fist of all, sorry for my bad english...
> 
> We "think/found" a technic to manage user action through a web
> interface. And I like to know your opinion about it.
> 
> The goal is to trigger actions through the server without using cgi ( or
> mod_perl ) fake pages.
> 
> The actions are managed by a Content Handler on a location:
> 
> 
> An example is better than long ( bad writen text ) so:
> 
> 
>   /action/Client/Add
> 
> Is parsed to obtains an object type ( "Client" ) and an action to
> perform ( "Add" )
> 
> $object = "Client"
> $method = "Add"
> 
> and posted data are read in $fdat ( hash table ref )
> 
> Then a perl package is found regarding the object type.
> 
> $package = MyNameSpace::Client;
> 
> An the action is called on that package.
> 
> The problem we have was that we wanted the handler to be able to call
> any function available on any authorised package, whithout using a
> dispatcher
> with a long
> if() {
> }elsif(){
> }elsif(){
> }else{
> }
> 
> To sumup, here want we are doing:
> 
> 1: parsing URI, to obtain a package and a method
> 
> 2: look if action is allowed on that package, by this user ( with a
> session management ).
> 
> 3: build a string  $str = 'MyNameSpace::Client->Add( $session, $fdat
> )',  $fdat are the data posted throught the handler
> 
> 4: calling $return = eval $str.
> 
> 5: find a redirection page for that ( package, action, result )
> 
> That all, it's work fine and it's allowing to call package/object methods whithout 
>having fake pages to maintains.
> 
> Comments are very, very welcomes
> 
> --
> Don't be irreplaceable, if you can't be replaced, you can't be promoted.
> 
> 
> 
> 

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Connection Pooling / TP Monitor

[Matt Sergeant]

On Fri, 27 Oct 2000, Tim Bunce wrote:

> On Thu, Oct 26, 2000 at 08:47:20PM +0100, Matt Sergeant wrote:
> > On Tue, 24 Oct 2000, Jeff Horn wrote:
> > 
> > > However, I am also aware of a _major_ ISP that implements their email
> > > system using a _major_ RDBMS that has had problems that are best
> > > solved via connection pooling.  Essentially, the time it takes them to
> > > search through all the cached connections is nearly as long as the
> > > time it is taking to read/write to the database.  Although, I'm not
> > > implementing email as this ISP is, I think that scalability in my case
> > > may definitely run into similar roadblocks.
> > > 
> > > I am interested in hearing from anyone that has tried to implement
> > > true connection pooling either within Apache or as an external
> > > process.  I'm particularly interested in hearing about implementations
> > > that could be made to work or are done using Perl and DBI/DBD.  I am
> > > mostly interested in things that are Open Source or licensed like Perl
> > > itself.
> > 
> > Having just returned from ApacheCon, I can honestly recommend looking at
> > mod_backhand to simply have a few servers that run the DBI pool, and have
> > database intensive requests go to those servers. It is a *very* cool
> > solution to just these sorts of scalability problems.
> 
> To redirect incoming url's that require database work to mod_perl 'heavy'
> servers? Just like a smarter and more dynamic mod_rewrite? Yes?

Yes basically, except its not a redirect. mod_backhand can use keep-alives
to ensure that it never has to recreate a new connection to the heavy
backend servers, unlike mod_rewrite or mod_proxy. And it can do it in a
smart way so that remote connections don't use keepalives (because they
are evil for mod_perl servers - see the mod_perl guide), but backhand
connections do. Very very cool technology.

> Or, here's an odd thought that just crossed my mind...
> 
> You could have a set of apache servers that are 'pure' DBI proxy servers.
> That is, they POST requests containing SQL (for prepare_cached) plus
> bind parameter values and return responses containing the results.
> 
> Basically I'm proposing that apache be used as an alternative framework for
> DBI::ProxyServer. Almost all the marshaling code and higher level logic
> is already in DBI::ProxyServer and DBD::Proxy. Shouldn't be too hard to do
> and you'd gain in all sorts of ways.
> 
> Anyone fancy having a go? Let me know so we can discuss it in more detail.

Sounds like just a CORBA/RPC type thing. Wouldn't you be better off using
CORBA::ORBit?

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: [ RFC ] New Module Apache::SessionManager

[Matt Sergeant]

On Wed, 25 Oct 2000, Gerald Richter wrote:

> I have three anonations:
> 
> 1.)
> 
> $r->header_out(Location => $r->uri());
> 
> Also this code works with most browsers it doesn't conform to the HTTP
> specs. A location header must include a host part. Shouldn't be to hard add
> something like
> 
> $r->header_out(Location => 'http://' . $r -> server -> server_hostname .
> $r->uri());

+ port too.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Connection Pooling / TP Monitor

[Matt Sergeant]

On Tue, 24 Oct 2000, Jeff Horn wrote:

> However, I am also aware of a _major_ ISP that implements their email
> system using a _major_ RDBMS that has had problems that are best
> solved via connection pooling.  Essentially, the time it takes them to
> search through all the cached connections is nearly as long as the
> time it is taking to read/write to the database.  Although, I'm not
> implementing email as this ISP is, I think that scalability in my case
> may definitely run into similar roadblocks.
> 
> I am interested in hearing from anyone that has tried to implement
> true connection pooling either within Apache or as an external
> process.  I'm particularly interested in hearing about implementations
> that could be made to work or are done using Perl and DBI/DBD.  I am
> mostly interested in things that are Open Source or licensed like Perl
> itself.

Having just returned from ApacheCon, I can honestly recommend looking at
mod_backhand to simply have a few servers that run the DBI pool, and have
database intensive requests go to those servers. It is a *very* cool
solution to just these sorts of scalability problems.

PS: I'll have an ApacheCon report "coming soon".

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: MyClass::import() not being called.

[Matt Sergeant]

On Thu, 19 Oct 2000, Rodney Broom wrote:

> Good evening all,
> 
> I've got this happy little access handler that works just fine. Now I need for
> it to accept parameters through import(). The catch is that MyClass::import()
> isn't being called. I've done all of the obvious stuff, like including lots of
> debugging messages, reading the docs, reading the Apache modules book, and even
> searching the archives for this list, no help. Does anybody know what's
> happening here?

Show us some code! import won't be called if you go:

use MyClass ();
   

Because that's a way to stop import being called. And it won't be called
for:

require MyClass;

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ApacheCon Sunday Pub Meet

[Matt Sergeant]

On Thu, 19 Oct 2000, Tim Sweetman wrote:

> Matt Sergeant wrote:
> > 
> > On Thu, 19 Oct 2000, Tim Sweetman wrote:
> > 
> > > It's even worse than that! 10:30pm on a Sunday...
> > 
> > OK, then we have to head back to the Hilton (hotel bars are still allowed
> > to be open late, right?)
> 
> Hmm, not 100% on this one, but believe that hotel bars are only allowed
> to serve alcohol to their residents after that time. This is fine if you
> are all staying in the Hilton. 
> 
> I'm not. But then I live within a fairly short distance. :)

All back to your place then :-)

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

ApacheCon Sunday Pub Meet

[Matt Sergeant]

How about Harvey Floorbangers, from 7 till late. (erm, I think late might
still be 11pm for england *sigh*)...

"With a name like Harvey Floorbangers you'd expect this to be a cheesy
theme bar with singing bar staff and signed guitars on the
wall. Thankfully, this is actually a traditional English pub frequented by
locals and visitors to the Olympia Exhibition Building across the road."

Sound OK to everyone? (Stas, I'm sure they serve tomato juice too...:)

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ApacheCon Sunday Pub Meet

[Matt Sergeant]

On Thu, 19 Oct 2000, Tim Sweetman wrote:

> It's even worse than that! 10:30pm on a Sunday... 

OK, then we have to head back to the Hilton (hotel bars are still allowed
to be open late, right?)

Of course my talk is on the Monday, maybe 10:30 would be a good
thing. (what am I thinking!)...

> 
> Matt Sergeant wrote:
> > 
> > How about Harvey Floorbangers, from 7 till late. (erm, I think late might
> > still be 11pm for england *sigh*)...
> > 
> > "With a name like Harvey Floorbangers you'd expect this to be a cheesy
> > theme bar with singing bar staff and signed guitars on the
> > wall. Thankfully, this is actually a traditional English pub frequented by
> > locals and visitors to the Olympia Exhibition Building across the road."
> > 
> > Sound OK to everyone? (Stas, I'm sure they serve tomato juice too...:)
> 
> 

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: [OT] uploaded files and multi-paged forms

[Matt Sergeant]

On Thu, 19 Oct 2000, Alexander Farber (EED) wrote:

> Matt Sergeant wrote:
> > Not multiple times, but let them upload and store in a temp file, which
> > you can store the filename as a hidden field. Use File::MkTemp to create
> > the filenames.
> 
> Thanks for the advice, but doesn't File::MkTemp have a race condition? 
> The subroutine File::MkTemp::mktemp does following (comments are mine):
> 
>$keepgen = 1;
> 
>while ($keepgen){
>  
>  # generate a random file name and put it into $template
> 
>  if ($dir){
> $lookup = File::Spec->catfile($dir, $template);
> $keepgen = 0 unless (-e $lookup); # isn't it a race?
>  }else{
> $keepgen = 0;# here it doesn't even check -e
>  }
>
>  next if $keepgen == 0;   # also, why this check?
>}
>return($template);
> 
> This looks as a bad quality module to me or am I awfully wrong? 

Its only insecure if you don't use sysopen($fh, $newname, O_RDWR | O_EXCL
| O_CREAT) (and then get a new filename if that failed 'cos the file
existed).

File::Temp is a slightly more secure alternative, doing the above line for
you.

You should also take an MD5 hash of the contents of the file to ensure
they don't change in the lifetime of the request.

Sorry, but I don't mention these things because they are obvious to me
these days.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: [OT] uploaded files and multi-paged forms

[Matt Sergeant]

On Thu, 19 Oct 2000, Alexander Farber (EED) wrote:

> How do you handle uploading files when using multi-paged
> forms (for example entered text and a picture are previewed
> before storing into the database and special directory)?
> 
> Uploaded files can't be passed as hidden fields, right?
> So do you let your users to upload the same file several
> times and then delete the temporary files with a cron job?

Not multiple times, but let them upload and store in a temp file, which
you can store the filename as a hidden field. Use File::MkTemp to create
the filenames.

And delete temp files older than 60 minutes or so periodically.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: OT: ApacheCon/Europe

[Matt Sergeant]

On Wed, 18 Oct 2000, Perrin Harkins wrote:

> Gunther Birznieks wrote:
> > 
> > Just wondering who all from mod_perl is going to ApacheCon/Europe next week
> > and are there any plans to get together like there was at PerlCon.
> 
> I'm going to be there.  Some kind of get together would be cool.  I'd
> like to hear about what other people are working on.

Well there's nothing yet planned for Sunday night, how about we meet in
some pub near the Olympia/Hilton ?

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: XML help (offtopic)?

[Matt Sergeant]

On Wed, 18 Oct 2000, Adi wrote:

> Have you looked at SOAP::Lite and the rest of the SOAP:: hierarchy on CPAN? 
> They may not be of direct help if you've already got a home-grown XML transport
> protocol, but it might give you some good ideas.  And, it may save you lots of
> time in the long run if you can convert your home-grown XML system to use the
> SOAP standard.
> 
> BTW, has anyone played with these SOAP modules much?  Specifically, are they
> well-written / optimized for mod_perl?

I've played a little bit with SOAP::Lite. Its a great concept, and just
seemed to work, except in certain cases, for example you can't pass a DBI
handle over SOAP, obviously, and the same goes for globs and
filehandles. But other than that its almost transparent!

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ht_time vs. strftime

[Matt Sergeant]

On Tue, 17 Oct 2000, David E. Wheeler wrote:

> Matt Sergeant wrote:
> 
> > You should still switch to Time::Object. Loading POSIX.pm still loads in
> > the .so which contains loads of cruft for things you don't
> > want/need. Whereas loading Time::Object is a lot smaller. Of course I'm
> > not sure how you'd fix the isdst thing with Time::Object, since it does
> > strftime internally...
> 
> Perhaps you could add something like ht_time() has - it takes a third
> argument indicating whether the time passed is UTC. If it is, it uses
> gmtime internally, otherwise it uses localtime. And it looks like
> ht_time()'s implementation of gmtime() properly returns the time zone
> and doesn't add in DST stuff. Is that doable in Time::Object, or are you
> using Perl's gmtime() there?

Its doable - I could add in the code for ht_time almost verbatim, although
I *am* using Perl's gmtime.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ht_time vs. strftime

[Matt Sergeant]

On Mon, 16 Oct 2000, David E. Wheeler wrote:

> Matt Sergeant wrote:
> > 
> > On Mon, 16 Oct 2000, David E. Wheeler wrote:
> > 
> > I'm confused. Why are you using gmtime then?
> 
> Because if no time is supplied, I want it to default to GMT. I'm setting
> up an app in which the database will store date/time in GMT only, but
> will serve it out to users in their own local timezones. So sometimes
> it'll be GMT and sometimes it won't.

Gotcha.

> BEGIN {
> if ($ENV{MOD_PERL}) {
>   use Apache::Util;
>   $format_date = \&Apache::Util::ht_time;
> } else {
>   use POSIX;
>   $format_date = sub {
>   POSIX::strftime($_[1] || $_[0] ? "%a, %d %b %Y %T %Z" :
>   "%a, %d %b %Y %T GMT", $_[0] ? localtime($_[0]) :
>   (gmtime)[0..7]);
>   };
> }
> }

You should still switch to Time::Object. Loading POSIX.pm still loads in
the .so which contains loads of cruft for things you don't
want/need. Whereas loading Time::Object is a lot smaller. Of course I'm
not sure how you'd fix the isdst thing with Time::Object, since it does
strftime internally...

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ht_time vs. strftime

[Matt Sergeant]

On Mon, 16 Oct 2000, David E. Wheeler wrote:

> Matt Sergeant wrote:
> > 
> > Sadly gmtime doesn't return any component indicating the timezone. Of
> > course why not print out GMT instead of %Z?
> 
> Because it won't always be GMT.

I'm confused. Why are you using gmtime then?

> > Alternatively, why not use Time::Object? It implements strftime without
> > the overhead of POSIX.pm, and does it in XS too.
> 
> Does it know Time Zones?

It just does strftime, so you can do what you've got below without loading
POSIX. Plus its OO so it makes more sense (IMHO).

> Here's what I've got so far. The idea is to get
> &$format_date to work correctly everywhere.
> 
> BEGIN {
> if ($ENV{MOD_PERL}) {
>   use Apache::Util;
>   $format_date = \&Apache::Util::ht_time;
> } else {
>   use POSIX;
>   $format_date = sub {
>   POSIX::strftime($_[1] || "%a, %d %b %Y %T %Z", $_[0] ?
>   localtime($_[0]) : gmtime);
>   };

I'm not sure I understand the correctness of this. Shouldn't it be:

gmtime($_[0] || time)

or

localtime($_[0] || time)

??

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: ht_time vs. strftime

[Matt Sergeant]

On Mon, 16 Oct 2000, David E. Wheeler wrote:

> Hi All,
> 
> Can anyone tell me why these are not equivalent? Shouldn't strftime know
> that the time returned from gmtime() is GMT? I'm trying to create a
> library that'll use ht_time when $ENV{MOD_PERL} is true, ans strftime
> otherwise. But they need to be consistent!
> 
>   use Apache::Util 'ht_time';
>   my $t = ht_time;
>   print "$t\n"; # prints "Mon, 16 Oct 2000 20:33:42 GMT"
> 
>   use POSIX 'strftime';
>   my $a = strftime("%a, %d %b %Y %T %Z", gmtime);
>   print "$a\n"; # prints  Mon, 16 Oct 2000 21:33:42 PDT

Sadly gmtime doesn't return any component indicating the timezone. Of
course why not print out GMT instead of %Z?

Alternatively, why not use Time::Object? It implements strftime without
the overhead of POSIX.pm, and does it in XS too.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Spinning httpd

[Matt Sergeant]

On Thu, 12 Oct 2000, Bill Moseley wrote:

> I'm in need of some ideas!
> 
> I have a spinning mod_perl process.  I installed a
> 
>   $SIG{USR2} = \&Carp::confess;
> 
> handler and it pointed to this line:
> 
>$cnt++ while $query->{query} =~ /(?:^|\s)[("]*\S$size\*/g;

Try:

$cnt++ while $query->{query} =~ /\G(?:^|\s)[("]*\S$size\*/gc;

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Fast DB access

[Matt Sergeant]

On Wed, 11 Oct 2000, Sander van Zoest wrote:

> On Wed, 11 Oct 2000, Matt Sergeant wrote:
> 
> Lots of places use databases for read-only queries. Having a database 
> that gets lots of similar queries that are read-only makes it an
> unnecessary single point of failure. Why not use the local disk and
> use rsync to replicate the data around. This way if a machine goes down,
> the others still have a full copy of the content and keep on running.

What is the actual use of the flat files in this case? Wouldn't generating
your HTML offline be better if your data is that static?

> You can do things terribly using Oracle and you can do things well using
> Oracle. The same can be said about just about everything. ;-)

You put your point well, and my only remaining point is that I think its
far far easier to screw up a flat file system by not taking into account
locking issues (just look at all those perl hit-counters that did it
wrong), and perhaps some reliability issues, than it is with a real
database. Caveat emptor, and all that.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: $r->dir_config at server startup?

[Matt Sergeant]

On Wed, 11 Oct 2000, Bill Moseley wrote:

> Can I get the value of a PerlSetVar at startup?
> 
> # Main server config
> PerlSetVar foo bar
> 
> 
> 
> 
> package My::Handler;
> use strict;
> 
> # Is there a way to get at 'foo'?
> my $foo = Apache->dir_config('foo');

Apache->server->dir_config('foo'); # IIRC

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Fast DB access

[Matt Sergeant]

On Wed, 11 Oct 2000, Sander van Zoest wrote:

> On Wed, 11 Oct 2000, Matt Sergeant wrote:
> 
> > Most modern DBMS software should be able to handle 50 queries per second
> > on decent hardware, provided the conditions are right. You're not going to
> > get anything better with flat files.
> 
> Hmm... I guess it all depends on what your queries look like, but you can
> get better results from flat files if you put them in a percise layout. 
> Granted if you are talking about having a million lines in a single
> flat file, then I definately agree with you.

I think the limiting factors are quite a bit sooner than a million
lines. What I'm trying to get across is that developers should be
focussing on letting the DBMS do what a DBMS does best - queries. The DB
is far better placed (and generally better developed) to do the
optimisation than trying to come up with a flat file strategy that works
with your system.

> I really think that sometimes going for a flat file layout *can* be much
> more reliable and scalable then RDBMS software. It all really depends on
> what you plan to do with the data and what you would like to get out of
> it.

I think you chose the wrong words there. I think a flat file layout can be
more performant than an RDBMS, but I don't think its going to be
more reliable or scalable than an RDBMS. There are far too many locking
issues and transaction issues necessary for the terms "reliable and
scalable", unless you're willing to spend a few years re-coding Oracle :-)

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: Fast DB access

[Matt Sergeant]

On Wed, 11 Oct 2000, Differentiated Software Solutions Pvt. Ltd wrote:

> Hi,
> 
> We have an application where we will have to service as high as 50
> queries a second. We've discovered that most database just cannot keep
> pace.
> 
> The only option we know is to service queries out of flat files. Can
> somebody give us pointers o n what modules are available to create
> flat file based database. Specically we want a mechanism to be able
> service queries which can return rows where values are greater than
> specified value. We are experiementing currently with dbm and
> DB::File. These seem to handle hashes quite comfortably. How do we
> handle these inequality queries.

I'd venture to suggest you look back at those RDBMS' again. What were you
using that couldn't handle 50 queries a second? What were your queries
like? How was the database optimised? Was the DB using the right indexes?

Most modern DBMS software should be able to handle 50 queries per second
on decent hardware, provided the conditions are right. You're not going to
get anything better with flat files.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

RE: XML::Parse segmentation fault

[Matt Sergeant]

On Tue, 10 Oct 2000, Geoffrey Young wrote:

> > On Mon, 9 Oct 2000, Herrington, Jack wrote:
> > 
> > > Is there some inherint problem with XML::Parser and mod_perl?
> > 
> > Yes. You need to recompile Apache with RULE_EXPAT=no.
> 
> according to Changes, this should be automatic as of 1.23...

Of course only if you compile Apache from mod_perl's Makefile.PL.

>From what I've heard, Greg Stein is now aware of the problem and willing
to work it out for the next Apache release. But whether that happens
remains to be seen...

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

RE: :Parse segmentation fault

[Matt Sergeant]

On Mon, 9 Oct 2000, Herrington, Jack wrote:

> This allows for XML parsing with no change to the Perl code.  I'm just not
> sure what I am losing in Apache (which is where I make the change).  What
> does losing EXPAT do to Apache?

You lose mod_dav, and maybe future modules that use the built in expat
support. But nothing serious.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\

Re: XML::Parse segmentation fault

[Matt Sergeant]

On Mon, 9 Oct 2000, Herrington, Jack wrote:

> Is there some inherint problem with XML::Parser and mod_perl?

Yes. You need to recompile Apache with RULE_EXPAT=no.

I'm hoping that now that expat has a standard distribution that the Apache
team will be proactive in fixing this bug.

-- 


/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\