bkietz commented on issue #38309: URL: https://github.com/apache/arrow/issues/38309#issuecomment-1832334038
> Why is it a problem that the S3 filesystem has some additional APIs? This is a less subtle issue in python where it's a more common pattern to provide functions conditionally. In C++ there are a few patterns which could be used, each with their own tradeoffs. I think the most straightforward would be lazily initialized function pointers (this pattern is commonly used to normalize opengl implementations with varying extensions, for example libGLEW): - s3fs.h is installed alongside filesystem.h - it contains a minimal S3FileSystem subclass which provides the region accessor - it also contains a function pointer for `resolve_s3_region` which is initially null and is assigned an implementation as part of initializing libarrow_s3fs.so > FileSystemOptions The factory takes string in my example because the main entry point for filesystem creation is FromUri, which takes string (in which all implementation specific options would be encoded). - It would also be possible to register pairs of functions `Filesystem create_fs(Options), Options parse_uri(string)` if an explicit options class hierarchy is desired, but I'm not sure that would add value. - Alternatively we could have a single concrete options class which we parse from a uri string: this would amount to making [ParseFileSystemFromUri](https://github.com/apache/arrow/blob/84c15da1997559c37841dc16f9e2c70c643dd9d2/cpp/src/arrow/filesystem/util_internal.h#L55-L60) public, I think. This might be nice for unit testing. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
