Re[2]: [PEAR-DEV] Re: HTTP::Cache vs HTTP::Download and HTTP::Header

Hello Michael, >> MW> If one's not able to find and use information and transform >> MW> it into knowlegde, well, one can be called quite lost nowadays... >> MW> If you've got any suggestions to improve the situation, provide >> MW> them in a sensible way, we'll very much appreciate them. >> Well, I suggest to merge the functionality of them into one package, >> which could be called HTTP::Cache_Control. MW> HTTP_Download supports much more than caching. I know. I suggest to merge only caching functionality of these packages into one separate package which will be intended to provide HTTP cache control only. >>>>I can only presume, >>>>that HTTP::Download implements something like PEAR wget >> >> MW> HTTP_Download is no downloader. The name might *now* be confusing, >> MW> but when the project started it was a real tiny "send some data" class. >> MW> See the package description, cvs and the docs for more information. >> >> The name *is* confusing and I'm not interested in some package history >> as long as I can't do that I need. MW> Pardon? Let's assume we are speaking in the context of this thread's subject - caching functionality of different PEAR packages. You've said that the name of your work "might *now* be confusing" in the sense of caching techniques it provides. I mentioned, that this name *is* really confusing, because there wasn't any mention of forementioned cache controls. ^^^^^^ see below >> Where is something about Cache-Control here? MW> MW> http://pear.php.net/manual/en/package.http.http-download.setcache.php Sorry. I was unable to find this page in offline CHM manual. Though I've just redownloaded it, seems that the last update was almost year ago. =/ Cache feature is not mentioned here that's why all the confusion. >> I think it is downloader and descriptions confirm my thoughts. MW> http://pear.php.net/package/HTTP_Download Now I see. But the name is still somehow misleading. Where is package like wget then? =/ And still it would be convenient to have an ability to handle personalized and non-personalized content with one package. Also to use that package with Apache to provide support for generating ETags for images and static web-site content with only Apache Alias or mod_rewrite settings pointing to this package while serving static site parts, so package component can take path from rewrite rule and handle further operations for readfile() and ETag generation automatically. >> What is Ueber, BTW? =) MW> http://en.wikipedia.org/wiki/Ueber t --