Hi Colin, Thanks for initiating this discussion. I think some refactoring in sentry-provider definitely helps. - At a high level, we should at the least break it down into a client module and a server module, so that sentry clients do not have to depend on server jar for example. - There are some component specific stuff in it. Anything component specific should be pulled out into a separate module? - For AuthorizationProvider, we only have one implementation of it (ResourceAuthorizationProvider). Cannot think of a use case where we would want to implement it differently? - Functionality of ProviderBackend is kind of duplicated in AuthorizationProvider. Should the AuthorizationProvider be solely for acl checks?
Otherwise, your proposed layout looks reasonable to me. On Thu, May 19, 2016 at 8:20 PM, Ma, Junjie <junjie...@intel.com> wrote: > Hi all, > > For the sentry-provider, it will make person confusion because many > isolated concepts are included, eg, authorization provider, provider > backend, sentry service(server&client). > I suggest to refactor the structure of sentry-provider, for example, split > into 3 parts as following: > > sentry-authorization-provider > > sentry-provider-backend > |--- sentry-provider-backend-common > |--- sentry-provider-backend-file > |--- sentry-provider-backend-db > |--- sentry-provider-backend-cache > > sentry-service > |--- sentry-service-common > |--- sentry-service-server > |--- sentry-service-client > > This will make the structure clear and can avoid the problems as > SENTRY-1255<https://issues.apache.org/jira/browse/SENTRY-1255>. > What do you think? > > best regards, > Colin Ma > > -- Sravya Tirukkovalur
