perl-docs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: "What is mod_perl" additions
Date Tue, 11 Jun 2002 07:26:30 GMT
Per Einar Ellefsen wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org


Mime
View raw message