If the cache accepts a generic Object then over half of the features will not be available, though this may not be clear to new users.
If the user changes the configuration to use other features besides the simplest memory cache, then either excessive type checking or errors will result. Should the cache avoid errors by checking and casting? If so, should it throw an exception to the calling program? How should this be done when the problems are in the background? What exactly should we do and how should this be made clear to users of JCS. I hate to think that the cache will take in garbage and then sit there and gobble up resources. Configuration options can often introduce errors, but the kind that we open up by allowing Objects into cache could be especially sneaky. It isn't clear to me how they should be dealt with. It seems like a clearer alternative to establish a Serializable contract and stick with it, rather than misleadingly accept Objects and not be able to handle them. If we do accept an Object then we need to figure out how to clearly inform the user and the calling program about what will and will not work and when they have introduced errors. If we have a solution that makes sense for this problem then it doesn't matter much what the access classes take. Oh, I'm not sure if a first beta release needs to be backward compatible. I'd like JCS to be something of an easy alternative to JCACHE, but I don't want to make things confusing to stay compatible. There are already some fundamental differences. We may need to discuss whether JCACHE compatibility is a major goal that makes sense. Aaron > -----Original Message----- > From: Hanson Char [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 23, 2002 7:42 AM > To: 'Daniel Rall '; Hanson Char > Cc: ''Turbine JCS Developers List ' '; '''John McNally ' ' ' > Subject: RE: [patch] simple patches > > What you point out are really 1) a backward compatibility problem and 2) a > standard problem. > > For (1), what we can do is to > > i)Cut a release version of the JCS impl that conform to the use of Object, > so an existing system already using them will not break. > > However, such system will be using BUT the most trivial implementation of > the caching system, ie in-memory cache which discards overflow. Should > such > system be configured to use more advanced features, the code will break > anyway during runtime, and therefore requires code modification to use the > Serializable data type. > > ii)For all future releases, use Serializable as the signature. If an > existing system does not need any advanced use of caching, it basically > doesn't need to upgrade to the later releases. If it does, it needs to > use > Serializable anyway. > > For (2), if a standard is not good, it should be changed. Otherwise, it > won't scale up and will ultimately disappear/become pointless. The > original > design of the use of Object in the signature reflects a lack of foresight > and is only appropriate/applicable in the most trivial cases. > > Hanson > > -----Original Message----- > From: Daniel Rall > To: Hanson Char > Cc: 'Turbine JCS Developers List '; ''John McNally ' ' > Sent: 7/22/2002 5:45 PM > Subject: Re: [patch] simple patches > > Hanson Char <[EMAIL PROTECTED]> writes: > > > "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.) > > When dealing with an existing system which already uses such a cache > (and I'm certain that many systems do make use of such a varietal of > LRU/MRU cache), plugging in JCS is a lot simplier if existing > interfaces do not have to change. Such a system would find the > excellent and open source JCS implementation more desirable than their > own home grown approach. > > > What other cases do you refer to ? > > I was under the impression that other concerns had been raised. > Looking back over the archive, I see only restatements of this same > issue: > > http://archives.apache.org/eyebrowse/ReadMsg?listName=turbine-jcs-dev@ja > karta.apache.org&msgNo=259
