So for the time being should I update the English wiki to show that
0.6.30 is the latest stable release. It seems this would be best for
newcomers to understand rather than now it says 0.5.35 is latest. Yet
it may also be confusing for some to see 0.6.30 (at least until 0.7 is
branched) is also the latest dev release. Any way just let me know what
you think is best and I’ll update it or leave it alone.
The new cache feature in 0.7 sounds interesting - is there any where I
can learn more about what this is for and its benefits?
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
On Sun, 2008-05-04 at 09:34 -0700, Rt Ibmer wrote:
So for the time being should I update the English wiki to show that
0.6.30 is the latest stable release. It seems this would be best for
newcomers to understand rather than now it says 0.5.35 is latest. Yet
it may also be confusing for some to see 0.6.30 (at least until 0.7 is
branched) is also the latest dev release. Any way just let me know
what you think is best and I’ll update it or leave it alone.
Go ahead and mark 0.5.x as “legacy” and 0.6.x as “stable” with a section
mentioning that a 0.7.x “development” branch will soon be started.
Thanks for helping!
Cliff
On Sun, May 04, 2008 at 09:34:59AM -0700, Rt Ibmer wrote:
So for the time being should I update the English wiki to show that 0.6.30 is the latest stable release. It seems this would be best for newcomers to understand rather than now it says 0.5.35 is latest. Yet it may also be confusing for some to see 0.6.30 (at least until 0.7 is branched) is also the latest dev release. Any way just let me know what you think is best and I’ll update it or leave it alone.
Please, do as Cliff has suggested.
The new cache feature in 0.7 sounds interesting - is there any where I can learn more about what this is for and its benefits?
In first release cache will cache upstream responses on disk.
On 5/4/08, Igor S. [email protected] wrote:
The new cache feature in 0.7 sounds interesting - is there any where I can learn more about what this is for and its benefits?
In first release cache will cache upstream responses on disk.
Is that more or less like this?
http://hostingfu.com/article/nginx-and-mirror-demand
sounds like a sweet feature.
On Sun, May 04, 2008 at 02:33:01PM -0700, mike wrote:
On 5/4/08, Igor S. [email protected] wrote:
The new cache feature in 0.7 sounds interesting - is there any where I can learn more about what this is for and its benefits?
In first release cache will cache upstream responses on disk.
Is that more or less like this?
http://hostingfu.com/article/nginx-and-mirror-demand
No, cache takes into account expire time to refresh responses and
inactivity time to delete responses from cache.
On Mon, May 05, 2008 at 01:11:54AM -0700, mike wrote:
On 5/4/08, Igor S. [email protected] wrote:
Is that more or less like this?
http://hostingfu.com/article/nginx-and-mirror-demand
No, cache takes into account expire time to refresh responses and
inactivity time to delete responses from cache.
So basically that URL, with an LRU cache mechanism and expiry support?
No, requests are not directly mapped to filesystem. Instead md5 is taken
from the proxied URL and this hash is used to find response in cache.
Besides, the cached response has full header: for example, 404 response
may be cached. Also the response may be cached only if it was requested
no less than, e.g., 2 times for some time.
Igor - this sounds brilliant !
This is exactly what we need in my business to cache a large number
of dynamically generated images that are at the moment being stored in
HUGE monolithic directories.
I look forward to trying this.
Dave
On 5/4/08, Igor S. [email protected] wrote:
Is that more or less like this?
http://hostingfu.com/article/nginx-and-mirror-demand
No, cache takes into account expire time to refresh responses and
inactivity time to delete responses from cache.
So basically that URL, with an LRU cache mechanism and expiry support?
That could be ok, we issue very long ttls on those urls because we
expire them by a version number embedded in the itself.
The main value for would be in hashing the cache store.
Cheers
Dave
On Mon, May 05, 2008 at 06:43:44PM +1000, Dave C. wrote:
Igor - this sounds brilliant !
This is exactly what we need in my business to cache a large number
of dynamically generated images that are at the moment being stored in
HUGE monolithic directories.
I look forward to trying this.
I can give the current snapshot.
It ignores the backend “Cache-Control”, “Expires”, etc. headers, so
this is the main reason why I still did not release it.