On Aug 18, 2009, at 10:18 AM, Mario Ivankovits wrote:
Hi!
From personal experience, I've found working with it
to be awkward and brittle. I would much prefer to have each provider
subclass FileSystemOptions and provide the getters and setters
there. Then,
at least, you could do an instanceof on the FileSystemOptions and
determine
what options are actually supposed to be there.
Look, The FileSystemOptions holds options for various filesystem
implementations - at the same time!
The reason for this is, that, given the url is provided by the user,
you simply do not know which real implementation will be used.
Thus, you have to provide e.g. ftp settings and sftp settings at the
same time and let VFS decide which options to use - depending on the
URL provided by the user.
Why would you like to pass in an option-set using a concrete config
class if the URL is anything else then "concrete".
Also, a layered filesystem might require different settings e.g.
compression-level of a zip-file on an ftp share.
This might require you to configure the zip filesystem (compression)
AND the ftp filesystem (active/passive mode)
Also, the idea was to implement some sort of
GlobalFileSystemOptions, the filesystem implementation then does not
need to be changed, just the FileSystemOptions have to take care of
that.
IF you use the options in a way which allows you to know which kind
of filesystem will be used - good - but then the builder is just
another layer, but not awkward and brittle I think.
No. They are awkward and brittle. WebDavFileSystemConfigBuilder
extends HttpFileSystemConfigBuilder. The getInstance method has to
return an HttpFileSystemConfigBuilder since you can't change the
return value of an overridden method. So code calling getInstance has
to then cast it to the correct type to use it. Of course, The name of
the method could have been changed but then it would be instantiated
differently then every other ConfigBuilder.
I wont say that there aren't other ways to solve that, but using
simple inheritance and instanceof is not the correct way.
Hmmm ... what I can think of is to refactor things that way:
* FileSystemOptions holds just a map of configurations like
Map<Class, FileSystemOption>
* FileSystemOptions.set(Class vfsFilesystemClass, FileSystemOption
options)
FileSystemOption then can be a concrete instance of a set of
configurations for one specific filesystem, so you might have
HttpFileSystemOption, SftpFileSystemOption etc. Each of them holding
all possible filesystem options.
I actually like this a lot more than the current implementation.
However, it wouldn't allow the get and set methods to be exposed at
compile time on the root FileSystemOptions class. I think that can be
worked around pretty easily.
Sure, this completely breaks backward compatibility - and the
GlobalFileSystemOptions thing needs to be solved somehow.
The ConfigBuilders can be deprecated and I'm pretty sure they can be
made to interact with this structure fairly easily.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
