At 08:55 11.06.2002, Stas Bekman wrote:
Per Einar Ellefsen wrote:
At 05:59 11.06.2002, Stas Bekman wrote:
Per Einar Ellefsen wrote:
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.
I disagree with you, we will end up creating another set of docs. Be prepared to answer numerous questions regarding this section. I don't think that was the idea. This is "What's mod_perl", a teaser. For complete docs we have docs.
That's what I was trying to say all along. You're the one who said you wanted more description etc etc.
No, I said the descriptions are due where the code is unclear. And if you take the newbie, it's most likely everywhere. Which leads to a huge amount of docs.
My suggestion was to mention features with links to the documents exploring these in depth.
But then you don't get much of a feel of how mod_perl things look like, do you?
That's what you think because you know all this stuff. For newcomers the amount of information is overwhelming so it's not easy to get the right ballance with what to show and what not.
I suggest the following approach. For each category of features show *one* code sample which is very clear and shows how easy mod_perl is. The rest of the features in the same category are only to be listed with links where to read more. I believe this approach accomplishes the mentioned vision:
* it provides sampling, so you get to feel what it is like coding in mod_perl (easy, concise, fast, ...)
* it lists a bunch of the other areas which the newcomer may want to explore but doesn't provide the details inlined, instead linking to them.
mod_perl is not: * Application Frameworks (Axkit, ASP, ...)
Well, I'd say it *is*. TIMTOWTDI. People might come to mod_perl from different sides. If you think about mod_perl as a backend, people will come to mod_perl because some of their applications require it (Slash for instance).
That's right. But then those users who find those framework arrive to discover what's mod_perl, not the other way around. I doubt very much that people come to check out on mod_perl in search for application frameworks. I'm talking about those who don't know what mod_perl is.
Ok, I'll drop that.
see above, if we can rework it that way if you like what I've suggested. So pick some realy short and sweet piece of code that demonstrates the power and mention a few other 3rd party modules which are really useful and sought after.
My suggestion is not to drop what you've done but temporary hide those things. Keep them committed but don't link to them. Once 2.0 is released and these features can be used without problems, then they will be a great boon for the "What's mod_perl" section. All in its time.
Well, nothing's commited yet. But I was asking in a more general sense: after what you've said, I understand that the only one you would like to keep (maybe) is the 3rd party modules one. Am I right?
whichever way you prefer. Either keep them on your machine till the time comes, post them to the list as a patch, so we can retrieve it later from the archive, or both.
Also remember that once 2.0 is released and proved stable all the docs will be switching to 2.0 as the main mod_perl, so if we say mod_perl without the version we mean 2.0. of course it'll take a while, but that's the idea. When this happens all the Apache 2.0 support will become irrelevant and those new features will be just core features listed along with all other features existing since 1.0.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
