Github user joshelser commented on the issue:
https://github.com/apache/incubator-ratis/pull/4
Breaking this out to a top-level thread instead of being anchored on a code
segment:
> We are not talking about full fledged FileSystem API here, but some API
would help in adoption, taking into account familiar file system abstraction.
I had a chat with Ankit and Sergey about this one, trying to weigh the pros
and cons. A FileSystem-like API would give users some familiarity in working
with the LogService, but the general feeling was that we may be over-burdening
ourselves in the first implementation. There would be many things we could
potentially implement via a FileSystem like API which we wouldn't necessarily
need for HBase as an initial consumer.
I think we could explore using a FileSystem-like API in the future to
supplement a more minimal core API (closer to what is here already). Something
higher-level could also be done as we get closer to HBase's rearchitecting.
I think it's becoming pretty clear that HBase's new WAL API won't be
written using the notion of a File on a FileSystem (and instead use a
"stream-like" API at the core). I could see us integrating the Ratis LogService
into HBase via a FileSystem facade.
How do you feel about that, @VladRodionov? Are there any immediate concerns
which would limit how we're thinking about building out the LogService if we
didn't have a FileSystem facade?
---
