Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Tue, 18 Jun 2002, Slava Bizyayev wrote: Igor seems upset with the current (not still final) results of this discussion, which HE tried to turn selfishly to a wrong way. Impolite style of discussions accomplished with attempts to hide some information and to provide some fantasies instead of real results of professional research does not work on this professional mailing list. What you call impolite style is simlpy poor English. It's very hard to me to express my thoughts in correct and polite English. That's right, instead of the main discussion we've spent a lot of time to learn a lesson, how the impolite selfish guy playing fool with professionals is punished finally, but wasn't it a fun? Ok, let me consider the lesson is over, and we may now go back to the main subject of this discussion. Yes, Beavis, it was a fun ! (I bag pardon to all subscribers, I can not resist, it's last personal email) Igor Sysoev http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Mon, 17 Jun 2002, Slava Bizyayev wrote: Yes, absolutely. And no one on the earth may restrict your rights to log anything you feel important in your own handler. Just every overhead decrements the number of your prospective users. And when you try to dictate your very own needs (or fantasies) to be accepted as a standard, you are incorrect. It was my reply to Valerio_Valdez. He had asked me why I need logging. I had answered him. You said me once again about another ways of logging. I know them. Thank you. I do not try to dictate anyone my needs or fantasies. Relax and do anything in fixup handler and tutorial - I would try not disturb you in any way and hope that is the last my email on this subject. Igor Sysoev http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
It's not quite the truth again. It is not a private email; it is a public mailing list. Everyone writing here expects the replies and comments from any other subscriber, especially from the main speaker of the thread. Igor seems upset with the current (not still final) results of this discussion, which HE tried to turn selfishly to a wrong way. Impolite style of discussions accomplished with attempts to hide some information and to provide some fantasies instead of real results of professional research does not work on this professional mailing list. That's right, instead of the main discussion we've spent a lot of time to learn a lesson, how the impolite selfish guy playing fool with professionals is punished finally, but wasn't it a fun? Ok, let me consider the lesson is over, and we may now go back to the main subject of this discussion. Just a few important conclusions: It's nothing bad to be wrong, or to make mistakes. Everyone does sometimes. We join our efforts, knowledge, and expertise in discussions to help each other to make every job well done with full respect of efforts, knowledge, and expertise of every participant. That 's why we can compete successfully in this world. I firmly believe that Igor will be back in our discussions soon, equipped with right behavior, and no one of us will ever mention his old mistake. Thanks, Slava From: Igor Sysoev [EMAIL PROTECTED] It was my reply to Valerio_Valdez. He had asked me why I need logging. I had answered him. You said me once again about another ways of logging. I know them. Thank you. I do not try to dictate anyone my needs or fantasies. Relax and do anything in fixup handler and tutorial - I would try not disturb you in any way and hope that is the last my email on this subject. Igor Sysoev http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
From: Igor Sysoev [EMAIL PROTECTED]
Here is first part of criticism.
1. You should not mix proxies and browsers.
It's a question. I've been thinking about this, and decided to refrain from
diving into a long common discussion about features of spiders,
content-feeders, general indexing robots, etc. I wouldn't let reader to sink
in unhelpful features of specific web clients before giving him a real tool
to serve those guys in accordance with his own business requirements (which
could be opposite to my own preferences). I firmly believe that we'll have
to deal with those guys in future. To make it practically helpful we have to
study all possible features of all available web clients on permanent basis,
and keep the community informed about current conditions of network clients.
To date we have too limited number of practically useful facts to stick with
this problem. Even more, we have to double-check some of well-known facts,
because the life is going on. New versions of old known web clients are
emerging sometimes. Sometimes people can make mistakes. Everything is going
to be changed on the earth, including the structure of this tutorial.
2. As I said you MS Proxy has not mask at all. ^1\.1 is not a mask.
^Squid/ is incorrect mask.
Here is example of Via header of HTTP/1.1 request that goes
though Squid, MS Proxy and Oops:
1.1 proxy1.domain1.com:3128 (Squid/2.4.STABLE2), 1.0 PROXY2,
proxy3.domain3.com:3128 (Oops 1.5.22f1)
3. Proxy masks will not help. About 70% of all proxied request are going
through Squid and about 15% are going through MS Proxy.
So much safe way is to disable proxy requests at all instead of tring
to look mask.
Besides I suspect that most proxies handle compressed content
incorrectly.
I had checked only Squid, MS Proxy and Oops but there are many another
proxies. So I think you should disable gzip for all proxied request
or enable it for all proxied request if you do not care about old
broswer.
mod_deflate by default disable it.
Since Igor fails to explain clearly the features of his secret knowledge
in both English and Russian to me, I decided to double-check his information
with the source authorities. Indeed, I was lucky to have a short
conversation on [EMAIL PROTECTED] mailing list with Henrik
Nordstrom, who is developing the Squid proxy. Now I have a real mask for the
Apache::CompressClientFixup handler and some new conditions for successful
implementation of content compression, serving the requests passed through
Squid. I'm going to make the appropriate changes in the text of tutorial as
version 0.02 a few days later together with other changes. Just a little
fragment of my conversation with Henrik Nordstrom for those who care:
From: Henrik Nordstrom X
Sent: Thursday, June 13, 2002 7:15 PM
Subject: Re: [squid-users] Accept-Encoding header
# Squid-2.5 and later supports caching of objects having the Vary
# header.
#
# Squid-2.4 and earlier denies caching of such objects as it cannot
# support more than one entity per URL.
On Friday 14 June 2002 02:43, Slava Bizyayev wrote:
# Should we consider the Squid-2.4 the only version compatible with
# content compression (as long as it denies to cache anything
# accomplished with Vary header)?
#
# Please, could you specify the earliest version, which is working
# this way?
#
# Am I understand correctly that we should refrain from
# doing the content compression on httpd when the request is coming
# through the Squid-2.5 (even we reply with Vary)?
From: Henrik Nordstrom X
Date: Fri, 14 Jun 2002 02:57:01 +0200
Subject: Re: [squid-users] Accept-Encoding header
# Both are fully compatible with all forms of server driven content
# negotiation (file type, encoding, compression etc), as long as you
# send a proper Vary header indicating such negotiation is taking
# place.
#
# Squid-2.4 and earlier won't be able to cache the reply as Squid-2.4
# and earlier can only support up to one entity version per URL.
#
# Squid-2.5 will cache the reply if possible, and honors the entity
# variance indicated by Vary.
#
# Squid-2.6 will most likely also support ETag, allowing Squid to ask
# the server which if any of the variants it already has is suitable
# for satisfying the new request type. In Squid-2.5 each request type
# is cached individually.
#
# The detection of Vary as uncacheable was added very long ago, probably
# during the Squid-1.X versions.
#
# Regards
# Henrik
Does it make sense? For me it means that every fact which is coming from
Igor Sysoev should be double-checked independently prior to practical usage.
I guess some significant changes in the next version of the tutorial... On
other hand, I feel better, knowing that guys from Squid are caring about our
clients, and life goes on.
4. You should not unset Accept-Encoding. Better way is to set
$r-note('disable_gzip').
Sometimes it seems like Igor does not really understand what he is speaking
about. No comments.
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Fri, 14 Jun 2002, Slava Bizyayev wrote:
Does it make sense? For me it means that every fact which is coming from
Igor Sysoev should be double-checked independently prior to practical usage.
OK. It's your right.
I guess some significant changes in the next version of the tutorial... On
other hand, I feel better, knowing that guys from Squid are caring about our
clients, and life goes on.
I did not check how Squid work with Vary header because any value in
this header simply disables caching in MSIE. I prefer client caching
to compression.
4. You should not unset Accept-Encoding. Better way is to set
$r-note('disable_gzip').
Sometimes it seems like Igor does not really understand what he is speaking
about. No comments.
I mean that that you should not change any incoming header.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
From: Igor Sysoev [EMAIL PROTECTED]
Sent: Friday, June 14, 2002 3:53 AM
Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
I did not check how Squid work with Vary header because any value in
this header simply disables caching in MSIE. I prefer client caching
to compression.
It's not the truth again. I'm using Vary accomplished with Expires to
control MSIE local cache about half a year. Works fine.
4. You should not unset Accept-Encoding. Better way is to set
$r-note('disable_gzip').
Sometimes it seems like Igor does not really understand what he is
speaking
about. No comments.
I mean that that you should not change any incoming header.
?! No comments.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Fri, 14 Jun 2002, Slava Bizyayev wrote:
I did not check how Squid work with Vary header because any value in
this header simply disables caching in MSIE. I prefer client caching
to compression.
It's not the truth again. I'm using Vary accomplished with Expires to
control MSIE local cache about half a year. Works fine.
I have just checked 3 MSIE:
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
All of them had recevied responses like this:
HTTP/1.1 200 OK
Date: Fri, 14 Jun 2002 09:51:59 GMT
Server: Apache/1.3.22 (Unix)
Vary: Content-Encoding
Cache-Control: max-age=86400
Expires: Sat, 15 Jun 2002 09:51:59 GMT
Last-Modified: Tue, 09 Apr 2002 14:15:31 GMT
ETag: 1d3a9-65d-3cb2f783
Accept-Ranges: bytes
Content-Length: 1629
Connection: close
Content-Type: text/html; charset=koi8-r
All of MSIE do not cache responses. They even do not
send If-Modified-Since header.
Can you show me URL with Vary and Expires that MSIE would cache.
4. You should not unset Accept-Encoding. Better way is to set
$r-note('disable_gzip').
Sometimes it seems like Igor does not really understand what he is
speaking
about. No comments.
I mean that that you should not change any incoming header.
?! No comments.
How can I log a real Accept-Encoding header if you unset it ?
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
From: Igor Sysoev [EMAIL PROTECTED]
Can you show me URL with Vary and Expires that MSIE would cache.
You have this combination when you access my preview with your MSIE by
HTTP/1.1 with no proxy (it's still old version of
Apache::CompressClientFixup installed over there). The lifetime of local
cache is 5 minutes, defined by my Expires. Within this time the browser will
not even try to access the server when you try to reach the same URL.
Instead, it restarts the page from the local cache. It's important to point
out that all initial JavaScripts will be restarted indeed, so you can rotate
your advertisements and dynamic content when needed. The second important
point should be mentioned here: when you click the Refresh button, the
browser will reload the page from the server unconditionally. It's right,
because it is exactly what the end-user expects from the Refresh button.
It was tested several times on my commercial handlers. It works fine
anywhere (I mean no problem is reported to date). The only issue was
mentioned by our testers: the lifetime depends on time accuracy of client
side. If your local client's clock is running 1 hour back, the cached copy
of my preview will be alive 65 minutes on that machine...
4. You should not unset Accept-Encoding. Better way is to set
$r-note('disable_gzip').
Sometimes it seems like Igor does not really understand what he is
speaking
about. No comments.
I mean that that you should not change any incoming header.
?! No comments.
How can I log a real Accept-Encoding header if you unset it ?
There is more than one way to do this, using mod_perl.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Fri, 14 Jun 2002, Slava Bizyayev wrote:
From: Igor Sysoev [EMAIL PROTECTED]
Can you show me URL with Vary and Expires that MSIE would cache.
You have this combination when you access my preview with your MSIE by
HTTP/1.1 with no proxy (it's still old version of
Yes, your response is really cached at least in MSIE 5.5.
I have just investigate this.
Responses with Vary: Accept-Encoding and Content-Encoding: gzip
are cached by MSIE. The Expires header is not needed.
Responses with Vary: Accept-Encoding but without Content-Encoding: gzip
are not cached by MSIE.
Furthermore, responses with Vary: Any,dummy,words and
Content-Encoding: gzip are also cached by MSIE.
And as I said before responses with Vary: Any,dummy,words and
without Content-Encoding: gzip are not cached by MSIE.
All these was tested with MSIE 5.5 only.
4. You should not unset Accept-Encoding. Better way is to set
$r-note('disable_gzip').
Sometimes it seems like Igor does not really understand what he is
speaking
about. No comments.
I mean that that you should not change any incoming header.
?! No comments.
How can I log a real Accept-Encoding header if you unset it ?
There is more than one way to do this, using mod_perl.
I mean that handler can do following:
if ($r-headers_in(Accept-Encoding) =~ /gzip/
and not $r-note(disable_gzip))
{
do gzipping
}
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Sat, 15 Jun 2002, Igor Sysoev wrote:
I mean that handler can do following:
if ($r-headers_in(Accept-Encoding) =~ /gzip/
and not $r-note(disable_gzip))
{
do gzipping
}
I understand your point of view, even I prefer Slava's approach.
I'm asking myself why you will need to log that particular header.
It is not a provocation, I don't understand the usefulness of
logging the status of an header that can be deduced undoubtedly from
the signature of browser issuing the request.
Ciao, Valerio
Valerio Paolini, http://130.136.3.200/~paolini
--
what is open-source about? Learn, and then give back
Re: tutorials (was: Re: rfc Apache::Dynagzip)
From: Igor Sysoev [EMAIL PROTECTED]
Yes, your response is really cached at least in MSIE 5.5.
Thanks.
...
I mean that handler can do following:
if ($r-headers_in(Accept-Encoding) =~ /gzip/
and not $r-note(disable_gzip))
{
do gzipping
}
Should we consider this the only possible way to write compression handlers?
Folks used to implement some different approach (clear and simple), common
to all mod_perl compressors listed in the tutorial. It works fine. See
sources for details.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Wed, 12 Jun 2002, Slava Bizyayev wrote:
Since now the draft tutorial Features of Content Compression for Different
Web Clients (for Part IV: Client side facts and bugs) is available for
preview and discussion at
http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
Here is first part of criticism.
1. You should not mix proxies and browsers.
2. As I said you MS Proxy has not mask at all. ^1\.1 is not a mask.
^Squid/ is incorrect mask.
Here is example of Via header of HTTP/1.1 request that goes
though Squid, MS Proxy and Oops:
1.1 proxy1.domain1.com:3128 (Squid/2.4.STABLE2), 1.0 PROXY2,
proxy3.domain3.com:3128 (Oops 1.5.22f1)
3. Proxy masks will not help. About 70% of all proxied request are going
through Squid and about 15% are going through MS Proxy.
So much safe way is to disable proxy requests at all instead of tring
to look mask.
Besides I suspect that most proxies handle compressed content incorrectly.
I had checked only Squid, MS Proxy and Oops but there are many another
proxies. So I think you should disable gzip for all proxied request
or enable it for all proxied request if you do not care about old broswer.
mod_deflate by default disable it.
4. You should not unset Accept-Encoding. Better way is to set
$r-note('disable_gzip').
5. There are two unrelated mod_deflate. First is my mod_deflate for Apache 1.3:
http://sysoev.ru/mod_deflate/
It'd been tested for one year on loaded sites.
Second is expiremental module for Apache2 by Apache tream.
Next part will be about browsers bugs.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
On Wed, 12 Jun 2002, Slava Bizyayev wrote:
Since now the draft tutorial Features of Content Compression for Different
Web Clients (for Part IV: Client side facts and bugs) is available for
preview and discussion at
http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
About browsers.
First we should not mention any browser that does not send 'Accept-Encoding'.
So remove Opera 3.5 from list.
Netscape 4.x
All NN 4.x does not understand chunked content. And they should not.
Chunked encoding is part of HTTP/1.1 and NN4.x support HTTP/1.0 only.
It's server bug if server sends chunked response to HTTP/1.0 request.
And your devl4.outlook.net has this bug (I suspect 1.3.24 mod_proxy).
So remove this bug from list.
Netscape 4.0-4.05 understand gzip and x-gzip. They did not
send 'Accept-Encoding'.
MSIE 4.x
Code
$r-header_in('Range') 0
or
length($r-uri) 253
is wrong.
1. Range. We should send full (and probaly gzipped) response
to MSIE 4.x if it asks byte-range and our response can be gzipped.
We should disable byte-range but not gzipping.
2. $r-uri 253. Not only $r-uri but also $r-args, server name, port
and user name and password. In short - all without 'http://' prefix.
URI can be - http://name:password@host:port/uri?args.
So in mod_deflate I simply check r-unparsed_uri 200
MSIE 6.0
I do not understand this:
A: Unfortunately, IE6 (and perhaps earlier versions?) appears
to have a bug with gzip over SSL where the first 2048
characters are not included in the HTML rendering of the page
when refresh is pressed. It only seems to happen on longish
pages, and not when the page is first loaded. In fact, sometimes
it doesn't happen at all. The only current solution is to put
a 2048 character comment at the start of your longish pages
of all spaces (which compresses pretty well, fortunately).
If bug with first 2048 characters are NOT included in HTML rendering
then why to put 2048 character comment ? Comments do not included
in rendering.
FlashPlayer 4.x-5.x
Plug-in. Fails to decompress data received from the browser.
flash recieves all data from browser. But it can play gzipped swf
because all browsers (except NN 4.x for Windows) uncompressed them.
All flash players can not handle gzipped data received via loadVariables()
and XML.Load() (5.x).
You had mentioned Galeon and SkipStone but had not mentioned
Mozilla 0.9.1 and Netscape6.1b1 that have bug. Yes, this browsers
already old and rare but Galeon and Skipstone now include own version string.
It's much simply to translate from Russian my information than to try
to interpret it.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
From: Stas Bekman [EMAIL PROTECTED] Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip) Probably the best post it here first, so we can get it reviewed and commented on before we add it to the docs. Since now the draft tutorial Features of Content Compression for Different Web Clients (for Part IV: Client side facts and bugs) is available for preview and discussion at http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html . I strongly hope to make it much better with your help prior to submit for publishing. Any comments will be highly appreciated. Thanks in advance, Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
At 00:04 13.06.2002, Slava Bizyayev wrote: From: Stas Bekman [EMAIL PROTECTED] Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip) Probably the best post it here first, so we can get it reviewed and commented on before we add it to the docs. Since now the draft tutorial Features of Content Compression for Different Web Clients (for Part IV: Client side facts and bugs) is available for preview and discussion at http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html . I strongly hope to make it much better with your help prior to submit for publishing. Any comments will be highly appreciated. Looks great Slava! Seems to integrate the needed info. I guess those who know more about Gzip encoding can tell you more technically-wise, but as far as the general look it seems ok to me. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Sorry folks, I experience some access problems with devl4. Server is down temporarily. I'll let you know when ready to continue. Slava - Original Message - From: Slava Bizyayev [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED]; modperl list [EMAIL PROTECTED] Sent: Wednesday, June 12, 2002 5:04 PM Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip) From: Stas Bekman [EMAIL PROTECTED] Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip) Probably the best post it here first, so we can get it reviewed and commented on before we add it to the docs. Since now the draft tutorial Features of Content Compression for Different Web Clients (for Part IV: Client side facts and bugs) is available for preview and discussion at http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html . I strongly hope to make it much better with your help prior to submit for publishing. Any comments will be highly appreciated. Thanks in advance, Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
At 03:37 06.06.2002, Slava Bizyayev wrote: It's going to be something like Features of Content Compression for Different Web Clients for Part IV: Client side facts and bugs. We'll be able to discuss details next week. Ok, great Slava, thanks a lot! -- Per Einar Ellefsen [EMAIL PROTECTED]
tutorials (was: Re: rfc Apache::Dynagzip)
Per Einar Ellefsen wrote: At 15:36 05.06.2002, Valerio_Valdez Paolini wrote: On Tue, 4 Jun 2002, Slava Bizyayev wrote: I don't know should it be a kitchen of every system administrator, or somebody could volunteer to serve the public web site about the current conditions of different web clients and recommended masks?.. I can't host it on my devl4, because it is a development machine. That would be better to find some stable place, like mod_perl, or apache project ;-). Can you provide a compatibility list? I think that the new mod_perl site is looking for new articles, may be the first part of Apache::Dynagzip man page is a good candidate... You could add also known bugs and features. But I cannot decide what goes on mod_perl site :) Just like I would have said it myself :-) We're clearly looking for information, and I was especially watching this thread for possible inclusion. We have a nice place to do this, it's in our Browser bugs section. Depending on the size of the document, it might go there or in its own doc. Anyway, we welcome any submissions. Format is standard Pod. See http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8content-type=text/vnd.viewcvs-markup for style information, but don't worry too much about that, we'll fix that as we go. I just want to add some clarifications to Per Einar comment. Are we looking for not strictly mod_perl but closely related material, which matters to the majority of mod_perl programmers? The short answer: Tutorials - yes manpages - no articles - take23.org The long answer: Tutorials cover some interesting topics using several implementations. Tutorials are pretty much static and don't require much maintenance. We heartly welcome these. The ongoing discission of MVC is a good example of a tutorial candidate, templating comparison and *generic* tips and tricks are other ones. Manpages, which aren't the core module are not very welcome at this moment, as they usually require high level of maintenance, and we have hardly resources to cope with perl.apache.org. So at least for now, manpages aren't welcome. If you have feature tutorials, either submit those to take23.org or any other online zine. perl.com is looking for such articles. so does apacheweek.com. probable there are others. The new perl.apache.org is not a dump place for docs. The more irrelevant stuff we throw there the less added value the site will have, the harder it'll be to find something and the whole idea of expanding docs will do more bad than good. So new tutorials are definitely welcome, but re-read the first para to see the definition of a good candidate and so the existing tutorials at: http://perl.apache.org/release/docs/tutorials/index.html before submitting your tutorial. If your idea of tutorial doesn't fit into perl.apache.org's tutorial's idea, we will gladly link to it. --- Now back to the topic. If you can submit to us known problems with browsers and solutions that would be great. But please don't submit the Apache::Dynagzip manpage. __ Stas BekmanJAm_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
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Stas Bekman wrote: The ongoing discission of MVC is a good example of a tutorial candidate Incidentally, I already wrote a fair amount on this subject in the eToys-related tutorial: http://perl.apache.org/release/docs/tutorials/scale_etoys/etoys.html#Code_Structure There's a diagram, code examples, etc. I wasn't planning to write a spearate MVC one because I've already said most of it there. - Perrin
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Slava Bizyayev wrote: It's going to be something like Features of Content Compression for Different Web Clients for Part IV: Client side facts and bugs. We'll be able to discuss details next week. Sounds great, looking forward to it. Probably the best post it here first, so we can get it reviewed and commented on before we add it to the docs. __ Stas BekmanJAm_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
Re: tutorials (was: Re: rfc Apache::Dynagzip)
It's going to be something like Features of Content Compression for Different Web Clients for Part IV: Client side facts and bugs. We'll be able to discuss details next week. Thanks, Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Per Einar Ellefsen [EMAIL PROTECTED] Cc: Valerio_Valdez Paolini [EMAIL PROTECTED]; Slava Bizyayev [EMAIL PROTECTED]; mod_perl Mailing List [EMAIL PROTECTED] Sent: Wednesday, June 05, 2002 11:44 AM Subject: tutorials (was: Re: rfc Apache::Dynagzip) Per Einar Ellefsen wrote: At 15:36 05.06.2002, Valerio_Valdez Paolini wrote: On Tue, 4 Jun 2002, Slava Bizyayev wrote: I don't know should it be a kitchen of every system administrator, or somebody could volunteer to serve the public web site about the current conditions of different web clients and recommended masks?.. I can't host it on my devl4, because it is a development machine. That would be better to find some stable place, like mod_perl, or apache project ;-). Can you provide a compatibility list? I think that the new mod_perl site is looking for new articles, may be the first part of Apache::Dynagzip man page is a good candidate... You could add also known bugs and features. But I cannot decide what goes on mod_perl site :) Just like I would have said it myself :-) We're clearly looking for information, and I was especially watching this thread for possible inclusion. We have a nice place to do this, it's in our Browser bugs section. Depending on the size of the document, it might go there or in its own doc. Anyway, we welcome any submissions. Format is standard Pod. See http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8conte nt-type=text/vnd.viewcvs-markup for style information, but don't worry too much about that, we'll fix that as we go. I just want to add some clarifications to Per Einar comment. Are we looking for not strictly mod_perl but closely related material, which matters to the majority of mod_perl programmers? The short answer: Tutorials - yes manpages - no articles - take23.org The long answer: Tutorials cover some interesting topics using several implementations. Tutorials are pretty much static and don't require much maintenance. We heartly welcome these. The ongoing discission of MVC is a good example of a tutorial candidate, templating comparison and *generic* tips and tricks are other ones. Manpages, which aren't the core module are not very welcome at this moment, as they usually require high level of maintenance, and we have hardly resources to cope with perl.apache.org. So at least for now, manpages aren't welcome. If you have feature tutorials, either submit those to take23.org or any other online zine. perl.com is looking for such articles. so does apacheweek.com. probable there are others. The new perl.apache.org is not a dump place for docs. The more irrelevant stuff we throw there the less added value the site will have, the harder it'll be to find something and the whole idea of expanding docs will do more bad than good. So new tutorials are definitely welcome, but re-read the first para to see the definition of a good candidate and so the existing tutorials at: http://perl.apache.org/release/docs/tutorials/index.html before submitting your tutorial. If your idea of tutorial doesn't fit into perl.apache.org's tutorial's idea, we will gladly link to it. --- Now back to the topic. If you can submit to us known problems with browsers and solutions that would be great. But please don't submit the Apache::Dynagzip manpage. __ Stas BekmanJAm_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
