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?


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.

Well, if there's such a strong feeling about what I've done, I'll just drop it. I just spent my time from mifnight to 1 in the morning trying to make it something, but it's not worth it. Tell me what you *think* is good enough, and I'll drop the rest.

Well, Per Einar, there are two ways to accomplish things:

1) suggest and hopefully get the expected feedback
2) do what you think is right and hopefully it'll be accepted by the others

untill recently with docs the 2# was the only way to go, no hopefully things getting better and more people are willing to give a thought to proposal.

no problem :)

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?


We still try to keep a low profile regarding mod_perl 2.0, since too many things aren't completed yet. We do want early adopters, but those who know what they are doing find their way to mod_perl 2.0 by themselves. We don't want those that don't know what they are doing to try mod_perl 2.0, because we expect help from those testers (building debug Perl, mod_perl, supplying core traces, etc...) That's why these features aren't ripe as "What's mod_perl".

I understand.


-- Per Einar Ellefsen [EMAIL PROTECTED]



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



Reply via email to