On Aug 18, 2009, at 12:48 PM, Jörg Schaible wrote:
Hi Mario,
Mario Ivankovits wrote:
I wont say that there aren't other ways to solve that, but using
simple
inheritance and instanceof is not the correct way.
+1
The current solution is somewhat unconventional, but this way you
always
know exactly which options are available for your FS.
That argument doesn't fly. You'd get that from inheritance too.
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.
Sure, this completely breaks backward compatibility - and the
GlobalFileSystemOptions thing needs to be solved somehow.
This already exists with the DefaultFileSystemConfigBuilder that
provides
the UserAuthenticator. We actually derived from this class
which class? DefaultFileSystemConfigBuilder or UserAuthenticator?
to provide an
additional id as system option - simply to control which FileSystem
instances are shared (hashCode of the FileSystemOptions is part of
this
decision).
I'm not sure I understand this. Sample code would help. But I would
imagine something could be put in place to control which file systems
can be combined using the method Mario proposed above.
But you guys are giving me ideas on things to try.
Ralph
