>There are enough non-Serializable cases to justify keeping the
>interface for Object.
"In-memory cache which simply discards overflow" is the ONLY case, which is
not a good case as it suffers from the disadvtange of hard-wiring the user
code to the use of such specific cache and therefore likely to require user
code change if the cache system is configured to use something more
advanced. ("likely" unless the user code already mark the cache items as
Serializable.)
What other cases do you refer to ?
Hanson
-----Original Message-----
From: Daniel Rall
To: Turbine JCS Developers List
Cc: 'John McNally '
Sent: 7/21/2002 9:35 PM
Subject: Re: [patch] simple patches
Hanson Char <[EMAIL PROTECTED]> writes:
> But isn't it true that even in-memory cache will eventually come
across the
> problem of overflow, which therefore requires the ability for the
cache
> items to be serialized and saved in some secondary storage ?
>
> One can agrue the use of techniques such as SoftReference to avoid the
> memory overflow problem, but such implementation is the
exceptional/specific
> case rather than the standard/canonical.
>
> If the above argument is sound, the existence of a standard such as
JCACHE
> should not stop us from trying to change/enhance/improve the standard
> itself. Or, If the standard cannot be changed owing to non-technical
> reasons, I would say we should create our own (better) standard for
goods,
> rather than to bindly/strictly follow it.
You make a good case for changing the API -- I considered this
myself. However, if you look at an in-memory cache which simply
discards overflow (like some LRU/MRU implementations), polluting the
interface with the Serializable restriction is unnecessary overhead.
There are enough non-Serializable cases to justify keeping the
interface for Object.
- Dan
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
