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

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