Forget the gui admin tool. I agree that's not what commons is about. That could be an after the fact tool that's not in jakarta commons. The point was that a common caching API opens the door to other possibilities.
I agree, most applications only access the java.util.Map part of the caching application. Making the main access point of the cache API implement Map might not be a bad idea. Of course there are other areas where the major caching implementations overlap, mainly in regards to administration and the viewing of your caches. Obviously if your entire application accessses only the thin wrapper, changing implementations would be tremendously easier. On a project I was on in the past, we wanted to switch between JCS and EHCache when it was discovered that JCS had several bugs with disk persistance. Of course this was near impossible because our administration tools needed to talk to JCS. As a side note, I think many of the JCS bugs have been fixed since then. -----Original Message----- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 14, 2004 5:58 PM To: Jakarta Commons Developers List Subject: Re: commons cache > Baum, Karl wrote: > > >[snip]For the most part though, all good caching implementations only > >expose a get,put, and remove to the application. > > > That much of the problem sounds a lot like an implementation of > java.util.Map to me ... ie. all thats needed is to get all the caching projects to implement the Map interface and there is no need for a commons-caching. Also, you should know that I wouldn't support developing a web/GUI-based caching administraion interface in commons. Its not what commons is about. Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
