I think moving up interfaces to FileSystem or some abstract FileSystem class has a few benefits:
1. Application can potentially be made FS-agnostic, with hasPathCapabilities() check. At least, make the code to compile. 2. We will be able to add a contract test to ensure behavior is expected. The second one is more critical than (1). For complex applications such as HBase it is almost impossible to achieve true FS agnosticity without proper contract tests, as now I am starting to realize. This is where I am coming from. No need to make Hadoop application development harder than it already is. On Mon, Mar 27, 2023 at 4:58 AM Steve Loughran <ste...@cloudera.com.invalid> wrote: > side issue, as i think about what bulk delete call would also keep hbase > happy > https://issues.apache.org/jira/browse/HADOOP-18679 > > should we think about new API calls only raising RuntimeExceptions? > > The more work I do on futures the more the way we always raise IOEs > complicates life. java has outgrown checked exceptions > > On Fri, 24 Mar 2023 at 09:44, Steve Loughran <ste...@cloudera.com> wrote: > > > > > > > On Thu, 23 Mar 2023 at 10:07, Ayush Saxena <ayush...@gmail.com> wrote: > > > >> > >> Second idea mentioned in the original mail is also similar to mentioned > in > >> the comment in the above ticket and is still quite acceptable, name can > be > >> negotiated though, Add an interface to pull the relevant methods up in > >> that > >> without touching FileSystem class, we can have DFS implement that and > >> Ozone > >> FS implement them as well. We should be sorted: No Hacking, No Bothering > >> FileSystem and still things can work > >> > >> > >> > > This is the way we should be thinking about it. an interface which > > filesystems MAY implement, but many do not. > > > > this has happened with some of the recent apis. > > > > presence of the API doesn't guarantee the api is active, only that it may > > be possible to call...callers should use PathCapabilities api to see if > it > > is live > > > > > >> >
