I'm also curious if moving all file writing to the javax.servlet.context.tempdir + [jetspeed/cache | jetspeed/tmp | jetspeed/conf] location would be a good idea, at least as a default behavior that could be overridden in config. I'm working on such a thing to get jetspeed running in my corporate environment, which prohibits all file writes outside of that temp directory.
%regards -tk At 05:05 PM 4/17/2002 +0200, you wrote: >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:[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]>
