Hi Mario, 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. > > > 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. > 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 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). - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
