Today I learned that one of our users is having trouble uploading huge video files, and in tracking down the problem I saw that Cocoon is configured to store uploads into its own webapp directory tree. That filesystem here only has 2.5GB free because it's for code and I never expected it to fill because of user actions. I can expand the filesystem or (more likely) rejigger Cocoon to write uploads elsewhere, but I'd like to grouse about this practice and suggest something I'd consider to be better.
}rant on{
Webapp.s should never dirty their own directories; they should be told
where they can write *anything* that must be written. One should be
able to deploy a webapp into storage which will be mounted read-only
without causing anything to fail, provided that one configures paths to
needed writable storage.
}rant off{
(It seems I'm not a lone crank, in this respect. See
http://comments.gmane.org/gmane.comp.jakarta.tomcat.user/209017 for
comments by people who know Tomcat and the Servlet spec.s very well.)
Since DSpace needs to be configured for storing stuff anyway, I long
ago invented a dspace.cfg property "dspace.var" and recoded all of the
writable paths in dspace.cfg to interpolate ${dspace.var} rather than
${dspace.dir}. I'd like to suggest adopting this as standard
practice, to help sites that would like to separate code from data for
manageability or security reasons or just because it's an ingrained
habit. :-) Current behavior can easily be maintained by shipping a
config that defines "dspace.var = ${dspace.dir}"
That leaves Cocoon's scribbling all over itself unaddressed, so I'd
like to find some way to let Cocoon use e.g. dspace.var, and to make
it possible to configure these paths without people having to hack on
deep internal bits of Cocoon (or DSpace for that matter).
Digression: by reading the Servlet spec. and related matter, one may
come to believe that the ideal Servlet application exists packed
tightly in an opaque bubble, depending only on what the Container
provides to it from the outside world. It is handed Resources for
things like database and email connections, transaction monitors,
authentication Realms and the like. It is given environment objects
and Context parameters for configuration, and consumes immutable
configuration such as message catalogs from classpath resources. Its
only (nearly) direct contact with storage is through the
Container-provided temporary storage area, which is represented by a
File object under the Container's control.
It often seems that no one pays any attention to this design, but that
doesn't mean there are no good reasons for it.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
