My idea is to keep it the current way, that both services are accessed the same way. I am planning to use separate implementation classes for the DiskCacheEntry classes, so you dont need to use a lot of if(local) ... else ... statements.
-----Ursprungligt meddelande----- Fran: David Sean Taylor [mailto:[EMAIL PROTECTED]] Skickat: den 17 april 2002 17:39 Till: 'Jetspeed Developers List' Amne: RE: More about the disk cache If I understand, you plan on creating two services, one for caching remote resources, and one for normalizing access to local resources and allowing for write access to local resources. Will both services share the same interface and normalized resource names? Could you provide some examples... > -----Original Message----- > From: Erik Stensmo [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 17, 2002 8:06 AM > To: Jetspeed Developers List > Subject: SV: More about the disk cache > > > A good point from Santiago Gala [[EMAIL PROTECTED]]was: > ----------------------------------------------- > "Files are bad. They don't allow for abstractions like WebDAV > or RPC-like stuff, or even JDBC (you can get streams from > BLOBs, so the cache could be in a database). Those mechanisms > are needed when we start speaking replication, clustering, > etc., and files are no longer meaningful. Also, filesystem > paths are evil, as they change in Windows/Unix, etc. > > So, this API tried to settle for getReader()/getWriter(), as > a way to have the admin setting up all the storage mechanism, > while having a way to write character streams." > ----------------------------------------------- > > So one task of the cache would be to hide away where > resources are stored so that you can reference to a resource > instead of a file name e.g. c:\\tomcat\\..... You access a > file through the cache via a resourcename e.g. > /jcm/jetspeed-content.xml, but the "file" could actually be > stored in a database. For a file based implementation, you > already have a file and you only need to use that. > > There are already functions for this in servlets > (getResource()), but there is no API for writing to resources. > > > > > > -----Ursprungligt meddelande----- > Fran: David Sean Taylor [mailto:[EMAIL PROTECTED]] > Skickat: den 17 april 2002 16:37 > Till: 'Jetspeed Developers List' > Amne: RE: More about the disk cache > > > > I seem to have forgotten why we need a diskcache for local > resources. If its on the local file system, why bother > caching it again on the local file system? > > In reviewing the code, it looks like local files aren't > cached afterall. > > > -----Original Message----- > > From: Erik Stensmo [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 17, 2002 12:49 AM > > To: [EMAIL PROTECTED] > > Subject: More about the disk cache > > > > > > I am thinking of rewriting the disk cache, as a service and I am > > thinking about doing it this way. > > > > 1. Keep the current interfaces to the disk cache. > > 2. Move the implementation of the disk cache to the > services directory > > and implement it as a service 3. Keep the current class > > JetspeedDiskCache and make that class use the new cache, > but deprecate > > the getInstance() method. 4. Use a factory for retreiving the new > > cache, not a method of an implementing class. 5. Split the local / > > remote functionality in two separate implementation classes > -> cleaner > > code 6. Not implement any mehtods as public, that are not > defined in > > the interface. > > > > > > Any suggestions to this? > > > > > > -------------------------------------------------- > > Gnistra > > > > Erik Stensmo > > [EMAIL PROTECTED] > > > > Phone: +46(0)18 10 87 10 > > Mobile: +46(0)733 759 752 > > > > Home page: www.gnistra.se > > > > -------------------------------------------------- > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
