Re: [keycloak-dev] Storage SPI: Users, Clients, and ?

I see your point now. Please, go one with your PR or design document I'm sure you'll get tons of reviews as you are touching a quite sensitive area :) Stian can talk more about this, but maybe this is something for Keycloak.Next. Regards. On Mon, Jun 10, 2019 at 3:07 PM Justin Gross <jgross.biz(a)gmail.com&gt; wrote: > Thanks for your feedback Pedro. > > > > I apologize I think I may have misspoke or misrepresented my thoughts. A > design document might prove helpful in explaining. > > > > TLDR; > > > > I didn’t intend to advocate for a single multi-purpose SPI but rather a > “parent” SPI which both User Storage and Client Storage could inherit from > (implementation wise) and potential future storage SPIs. > > > > Looking over User Storage SPI and Client Storage SPI I see a lot of the > code in Client Storage Provider (and related files) as copied from User > Storage and code that is not specific to either and related only to storage > itself. There are more Client Storage Provider related stuff that, when > finished, will probably also just be a copy/duplicate of existing generic > code in User Storage Provider (and related). > > > > Given that most storage SPI’s will probably have similar “storage general” > interfaces and functions it would make sense to me to create a common > ancestor rather than continue to duplicate code in every specific storage > SPI thereby actually simplifying (instead of making more complex) the User > and Client (and other future) storage SPI’s. > > > > My proposition (I’ll PR to community) is that we move code that is not > specific to User Storage (or Client) but that is actually general code > (code currently being duplicated or soon to be if finishing Client Storage > SPI) into “storage” classes and interfaces. This would group together the > storage interfaces and functionality that are general and thereby > simplifies the production of new storage SPI’s as new storage SPI’s can > narrow their focus to the specific requirements you spoke of Pedro. > > > > Thank you, > > Justin Gross > > > > *From: *Pedro Igor Silva <psilva(a)redhat.com&gt; > *Sent: *Monday, June 10, 2019 8:03 AM > *To: *Justin Gross <jgross.biz(a)gmail.com&gt; > *Cc: *keycloak-dev(a)lists.jboss.org > *Subject: *Re: [keycloak-dev] Storage SPI: Users, Clients, and ? > > > > Hi Justin, > > > > Personally, I think that having a single and multi-purpose SPI can lead to > a much more complex and full of hacks to address the different requirements > when integrating with different sources and data. In any case, I would > suggest you to start a design document and send a PR to > https://github.com/keycloak/keycloak-community. So we can understand > better your proposal and discuss it. > > > > Regards. > > Pedro Igor > > > > On Sun, Jun 9, 2019 at 12:10 AM Justin Gross <jgross.biz(a)gmail.com&gt; wrote: > > Born out of necessity it looks like originally (for storage SPI) there was > only user storage SPI and eventually came a partial client storage SPI > motivated by a need for Openshift integration. The more I think about how > it could be finished, and the more I look at the user storage SPI, the more > I am finding code within user storage SPI that can be generalized as simply > storage SPI. > > Seeking feedback on refactoring existing user storage SPI related > interfaces to be agnostic to users and generalized as “storage SPI”. This > should reduce the need for duplicating similar code when implementing other > storage SPI (ie: client storage SPI). > > In the future I could see more storage SPI’s being created and I feel this > would be extremely useful. > > > Thank you, > > Justin Gross > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev