Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 30.06.2006 um 00:43 schrieb Vlad Seryakov:

> I am not going to argue, it is just old ns_cache used to have all
> functionality and was very popular and useful. Now we have more  
> limited
> ns_cache_XXX family and standalone ns_cache does not work anymore.
> I do not see who benefits from all this.

The point is to have simpler, better and more stable cache code.
Quality of the API does not necessarily relate to the size i.e.
number of calls. So, API with 10 calls is not more limited than
the API with 100 calls, if the 10 calls is all people "really"
need.

But, do not get me wrong. I'm not in favour of stripping functionality.
As far as I', concerned, ns_cache API can consist of only three
calls:

    ns_cache_create
    ns_cache_eval
    ns_cache_flush

More is not needed for the "usual" cache operation. Now, one
can imagine adding some operations on the cache vaules directly
like

    incr
    llength
    lindex

and atomic operations lile

    set
    exists
    get

which is all allright but in some "sense" diverts from the
base idea of cache: just temporary store values resulting
from hard caclulations.

Frankly speeaking, I do not have anything against expanding
this API to accomodate all that. If you look at the threading
extension, you will see the "thread::tsv" (thread shared variables)
which is nsv on steroids. So, I went there and added tons of additional
options and commands because nsv is designed for cross-therad storage
of values. You never go and purge nsv arrays on size and on time
i.e you never go and prune the nsv automatically. So the question is:
wny using nscache when nsv *may* be the more appropriate vehicle?
I'm not saying that it is in your particular usage case. I just say
that I *think* it would serve better. But you should know this better
because you write your own code.

I will going to backport the thread::tsv code from the Tcl
threading extension into the NS and this will bring you much more
power into nsv than ns_cache will ever have. It is just the question:
do you need AUTOMATIC purging (on time or size constraints) for the
values you keep now in ns_cache?

Please do not think that I'm blocking you from anything. I' m just
trying to understand the needs and provide optimal solution. If at the
end we see the need to expand ns_cache to handle all that nsv does
PLUS automatic entry expiry, then we'l do that. But then we'll know the
reason why and this will justify adding and maintaining more code.

So, relax. I'm the last person on the earth to block anybody ideas.
We'll sort all this out. But I just need *some* insights on how
this code is used in your application.  To make a good example,
I will try to write how I see that code from our's perspective i.e.
what we need and what not. This will be a part of a new message
under different subject.

Cheers
Zoran