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.
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.
From: Pedro Igor Silva
Sent: Monday, June 10, 2019 8:03 AM
To: Justin Gross
Subject: Re: [keycloak-dev] Storage SPI: Users, Clients, and ?
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.
On Sun, Jun 9, 2019 at 12:10 AM Justin Gross <jgross.biz(a)gmail.com> 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
keycloak-dev mailing list