Anrea, Niklas,
Looks like I'll be the one making the local changes :-O. FileObject is
more accurate. I don't use the commons VFS package, so was not aware of
a clash. Maybe FtpFileObject?
+----------------+
| |
| FtpFileObject |
| |
| +-----------+ |
| | metadata | | ----> database, etc
| +-----------+ |
| +-----------+ |
| | content | | ----> local disk, remote storage via
| +-----------+ | InputStream, OutputStream
+----------------+
The "object" is actually quite nice as it's self-contained as far as
handling information and content about itself. Just by using different
streams, FtpOutputStream, FtpInputStream, GzipCompressionStream,
TeeStream, and so forth, one has a lot of control over where the content
[and metadata] can be directed. It also lends itself nicely to caching
and serialization sans the content. FtpFileObject with an emphasis on
the "object" is a pretty good description of it.
Andy
Andrea Francia wrote:
Niklas Gustavsson wrote:
On 10/6/08, Andy Thomson <[EMAIL PROTECTED]> wrote:
In my opinion, I would leave the FileObject as-is, if it's really
causing
issues, make changes in a local copy. I suspect though, that as the
world
moves to more object-based storage, the local changes will be a major
problem. It's not just a simple name change, it's what it represents
:-).
I guess I might not be as forward thinking :-) I've changed the name
from FileObject to FtpFile. The reason being that I've always found
"FileObject" being such a wierd name (what is not an object in a Java
API?). I'll be happy to change the name again if someone has a good
idea for what it should be called. I'm not happy with FileObject, but
as always I could be persuaded.
The FileObject name will clash with the
org.apache.commons.vfs.FileObject in the case a Developer using Ftplet
decide to use the common-vfs to implements its FileSystemView.
FtpFile is not so good but IMHO is better than FileObject. I don't known
a better name.
