It's kind of hard to tell because this code is pretty old and has a lot of technical debt accrued over time, but it looks like the original developer wanted to provide a mechanism for a user-pluggable implementation to cache operations, but we also wanted to ask that implementation not to use a cache. My best guess is that it the decision to use it or not, depends on whether it's a high-performance operation. But ultimately, I think you're right, Mohammad, that it should be an implementation detail. That's something we'll probably work out when we try to clean up all the technical debt surrounding that part of the code.
On Fri, Oct 23, 2020 at 12:08 PM Mike Miller <[email protected]> wrote: > > This interface is not technically a part of the user API (see > https://accumulo.apache.org/api/) but it is a component that was designed to > be pluggable before Accumulo had a clean API. There are a lot of issues with > these pluggable interfaces, one of them being that they use internal > components that are not stable between releases. I recommend you use them > with caution. I recently made some attempts to design appropriate interfaces > we can promote to the API or the newer SPI but this is ongoing and is a > difficult undertaking. > > To answer your question, I am not sure and would have to dig into the > implementation details. > > On Fri, Oct 23, 2020 at 11:49 AM mhd wrk <[email protected]> wrote: >> >> Looking at PermissionHandler, I'm wondering why caching is not considered >> just as an implementation detail. What's the need for differentiating >> between cached and non-cached permissions at API level? How does Accumulo >> security decide which one to call? >> >> Thanks, >> Mohammad
