[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: VFS cache as impl detail, to what extent

[alesj]

"dimitris at jboss.org" wrote : 
  | From the outside I understand that caching should be an internal implementation detail/optimization non visible to the standard user or accessible over the simplified api.
  | 
What can be more simple than VFS::getCacheFile? :-)

"dimitris at jboss.org" wrote : 
  | Before we had URLs, everybody knew how they worked, server was working, there was nothing to configure, everyone was happy. With VFS we have started talking about cashing and weird options, and locking problems and threads and reapers and timeouts and what not. This is a step back, not forward. Some of it might be necessary, but it should be mostly invisible to the end user.
  | 
Afaik, this was all there before.
My guess is, it was just scattered all over the place, hence you didn't notice it.

Reading Adrian's CL history overview supports my 'theory':
 - http://www.jboss.org/community/docs/DOC-13267
"adrian at jboss.org" wrote : 
  | A major motivation for this change is to move the handling of the file locking problems (seen on Windows) or file handle leaks (seen on Linux) into one place.
  | 
;-)

"dimitris at jboss.org" wrote : 
  | The whole point is: we need to make it *simpler*. It has to be stable and fast for 80% of the cases. Our users shouldn't even know it exists - they shouldn't care and they shouldn't have to tinker with bean descriptors to make it work for them, except for rare circumstances.
  | 
Unfortunately we only learn the details by examples.
But that's called OSS and community feedback. ;-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203967#4203967

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4203967