Erik Stensmo wrote:
>Hello
>
>I have been investigating why the content management system do not work
>correcly, and found some bugs. One problems lies in the disk cache, which
>uses URL:s for filenames even for local files. It's easy to read from a URL,
>just open a URLConnection and read from the file, but writing is harder. The
>problem is how to get a foolproof way of retrieving the correct filename for
>the file to write to, since the URL might be a logical name, and there is no
>API to retreive the physical name of a URL.
>
>I suggest that we store the physical filename (the aboulute name) for a file
>if the file is local, so that writing to a file (via getWriter()) works
>correctly.
>
getWriter() was a first attempt to abstract this.
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.
Input/OutputStreams (byte streams) are also evil, as you need the extra
information of the character encoding used to render them meaningful,
and there is no simple way to propagate it. Also, in java conversion
between bytes and characters is expensive, and our policy here is:
convert-once, process everywhere :) i.e., deserialize as early as
possible, process characters all time inside Jetspeed, and only
serialize at the end (when writing the response for the browser).
The intention in this component is that entries are accessed through
getEntry("url").getReader()/getWriter() always. Currently we have the
problem to distinguish between "writable" entries and "read-only" ones.
This could be solved by throwing a IOException("URL is not writable")
when getWriter() fails, and letting the user code take care of this.
>
>I could implement this functionality if anybody else do not want do do it.
>
Go for it, as most of us are overwhelmed and will not be able to do it,
even if willing.
What do you think about these comments? Do they go into your line of
thinking?
>
>
>Erik Stensmo
>
>--------------------------------------------------
>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:[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]>
