On 6/30/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
To mimic Tcl variables usage or any memory access operations, by having _set, _get, _exist, _unset with additional _eval will make it complete and will allow to use by the developer as he sees fit. These are basic operations, on top of that a developer can build different systems, not just one way. It is development tool, not complete system, we can never anticipate all possible usages of cache API, so providing low-level primitives in my opinion is good direction.
_set, _get and _exists aren't cache primitives because they're not thread safe.
> > 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
These aren't atomic. For example, after ns_cache_exists returns the value may exist or not due to cache flush, expiry, etc., you really don't know.
> which is all allright but in some "sense" diverts from the > base idea of cache: just temporary store values resulting > from hard caclulations. Tcl variable fall into this category as well and has more operations and other tools to work with. Why limiting cache, in some sens it is shared variables by more than one thread with locking, expiration if set, and timeouts if set. what is wrong to treat cache as more powerfull tool.
Tcl variables work in a completely different environment, they are not intended to be thread safe.
