Per Einar Ellefsen wrote:At 19:38 10.06.2002, Stas Bekman wrote:
Per Einar Ellefsen wrote:
I have added sections below "Configure Apache with Perl" (the more >> documents).
got it:
* The first example is the code but no config. Are those examples intented to be just a teaser or fully functional? If the latter we need to add a sample config section.
Well, I was only intending it as a teaser, because I don't want to go creating a complete application using sessions. That handler doesn't do anything, it just shows how easy it is to get session info and use it.
easy to whom? One must wear a newbie hat (perhaps a hat of someone who doesn't know perl very well) when designing such a doc.
On the opposite it's very easy to turn the new person away, if things seem to complicated (to him!).
Therefore it's probably to present just a little, along the lines that Bill has done and explain things.
Please be careful not to overdo here, the size does matter, the other way around.
I'll try and do my best, and take another stab at this. I don't however want to make things overly simplified: some things should be ok for newbies, but some other things are more oriented towards the experienced web programmer. For example, to understand "Sessions" you have to have some experience: my example was more directed to Java/PHP programmers having used sessions before, and might be amazed about how easy it is with mod_perl.
* The same here:
start/tips/app-servers.html
it's good for slides, but not enough padding for a document. The start is great, but I believe huge snippets of code without explanation are bad, unless you use it as a teaser and look-n-feel demo.
Once again, I don't want to being explanation. The point is just to show example syntax, which some PHP/ASP/anything-junkies might love. Explanation is good for docs, this is mostly to attract people. Of course I could add a sentence or 2, but I don't want more than that.
what good is example if I don't understand it and the language it's written in? talking about ASP, AxKit and other examples.
Well, they'll have to learn Perl anyway. The ASP example wasn't complicated at all, anyone with 2 minutes programmng experience would understand it. I'll extend more on comments as I said above though. For the Embperl one, I'll make it easier, removing the DB stuff (the table things is most interesting). As for AxKit, there wasn't even any Perl in it! XML is the hit of the year, so let's try and drag people into it!
I think it's better to just say that the feature is available with a link to a proper doc, rather just making the person go confused.
* Apache 2.0 support
I doubt this is a good title. Of course we support Apache 2.0. This is not a feature, this is *the* thing. Remember that after awhile 2.0 will be *the* version, so it'd be silly to advertise it as a feature. moreover currently 2.0 support is alpha-beta yet.
i suggest to rename it. "Apache 2.0's new features support"
Ok. But anyway, once mod_perl 2.0 comes into General Availability (or whatever we call it), this doc will have to be changed. For now, mod_perl 1.0 is the king, and mod_perl 2.0 is something people might want to have fun with.
Fun? You are mistaken again. This section is for *newbies* not for those who use mod_perl for years and looking for that kind of fun.
Imagine a new person coming to us and we give him this fun. I doubt this person will stay with us. If you want to give fun, give them something that works and something that they will have very little frustration with.
This doc isn't a "working examples" page. It's supposed to show basic syntax and how *easy* things are. Writing a protocol server with mod_perl looks *easy* with Apache::Echo. Do you have any other ideas for the Apache 2.0 page?
"Easily create custom modules that become part of Apache""Gain access to all request stages"
should probably come before registry.
True, but as an eye-catcher, the first point would be "Faster CGI" as something people unfamiliar with these whole handler-thingies would tick on. For me, this page isn't anything else than advertising: we're trying to catch programmers and managers alike, and it's most likely they are already running CGI which they want a replacement for.
There are many other competing products that speedup CGIs. The strenth of mod_perl is in Apache API not in Registry, even though many people do use registry.
As Bill said and Drew said, Apache::Registry seems important to me. You point at newbies, but newbies are more inclined to know about CGI than anything related to handlers. They'll learn that along the way.
Ok, we drop it then...?By the way: src/start/tips/logging.pod isn't used. Should we maybe delete it?
you mean logging? ok, unless someone comes up with a simple easily understandable example .
+1.
-- Per Einar Ellefsen [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
