AW: AW: Dynamic loading of FileSystemProvider instances

[Christian Schlichtherle]

> I don't think I understand this. It looks like you are dynamically
> generate a URI scheme per mount point and it's not clear (to me anyway)
> if this means you have a file system provider per mount point (which
> doesn't make sense). Are these URIs internal to your provider as they
> doesn't seem to be something that should be exposed to anyone using
> this
> API?

First, I need to differentiate between Path URIs (those returned by
Path.toUri()) and FsPath URIs (a class in the TrueZIP Kernel). 

This seems to be required because Path URIs need to be hierarchical and each
FileSystemProvider can use only one scheme which is determined at compile
time. An example URI could be "tzp:/archive.zip".

In contrast, FsPath URIs are opaque and the available schemes are figured by
locating file system driver service instances on the class path (by means of
ServiceLoader as you do). The corresponding FsPath URI for the Path URI
above could be "zip:file:/archive.zip!/". However, another meaningful
mapping could be "zip:http://somehost/archive.zip!/", too.

This mapping needs to be done in FileSystemProvider.newFileSystem(URI, Map)
and FileSystemProvider.newFileSystem(Path, Map). Now how do I tell the
FileSystemProvider to do the mapping? It seems reasonable to create
different FileSystemProvider instances for different "realm"s, i.e. root
mount points.

For example, if I had a FileSystemProvider which maps the Path URI scheme
"tzp" to the FsPath URI "file:///C:/", then the FileSystemProvider would
create a FileSystem for the Path URI "tzp:/archive.zip" (FsPath URI
"zip:file:///C:/archive.zip!/"), another one for "tzp:/archive.tar.gz"
(FsPath URI "tar.gz:file:///C:/archive.tar.gz!/") and another one for
"tzp:/dist.tar.gz/app.jar" (FsPath URI
"zip:tar.gz:file:///C:/dist.tar.gz!/app.jar!/").

Another FileSystemProvider could map everything to the root mount point
"http://somehost/" for the same Path URIs.

I don't see how else it could work.

Then I need a way to figure which FileSystemProvider instances I need at run
time. I would enumerate all file system drivers and filter for the
non-federated file system drivers. If I find a non-federated file system
driver for the FsPath URI scheme "file", I might install a
FileSystemProvider for mapping from Path URI schemes "tzp" (default) and
"tzp.file". If I find a non-federated file system driver for the FsPath URI
scheme "http", then I might install a FileSystemProvider "tzp.http". If I
find a non-federated file system driver for FsPath URI scheme "https", the I
might install a FileSystemProvider "tzp.https", and so on.

I'm open for better ideas, but this is the only option I see to support the
dynamic discovery of file system drivers with FileSystemProvider instances.

Best regards,
Christian