Hi, Gabriel. I'll give you one set of answers. Maybe you'll get another :) > - Is the filesystem API considered "production" safe or only suggested for > testing/debugging? Put a gun to my head, and I'd say no. For example, it is unsafe to run multithreaded as there are race conditions in the impl [1]. Also, it only runs a subset our our existing integration tests. [2] Production means something different for different people, but I wouldn't suggest it for production. > - Could an alternate way of storing metadata be implemented, for > example in a properties file named <id>.metadata stored alongside > with the object file? Yeah I've seen this approach in the past, and that would certainly be more portable. > - I could implement a file metadata storage by wrapping > FilesystemStorageStrategyImpl, but I don't think this is a good idea to > wrap it as I have to re-implement a few classes to have the dependency > injection work correctly. Perhaps there's a way to isolate the metadata aspect. Personally, I would raise a Jira [3] asking to remove the requirement of extended attributes.
-A [1] https://github.com/jclouds/jclouds/blob/master/apis/filesystem/src/main/java/org/jclouds/filesystem/strategy/internal/FilesystemStorageStrategyImpl.java [2] partially implemented https://github.com/jclouds/jclouds/tree/master/apis/filesystem/src/test/java/org/jclouds/filesystem/integration vs https://github.com/jclouds/jclouds/tree/master/blobstore/src/test/java/org/jclouds/blobstore/integration/internal (conceding blob signing or public acl are not relevant) [3] https://issues.apache.org/jira/browse/JCLOUDS
