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
On Mon, Jun 10, 2019 at 3:07 PM Justin Gross <jgross.biz(a)gmail.com> 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.
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 <psilva(a)redhat.com>
*Sent: *Monday, June 10, 2019 8:03 AM
*To: *Justin Gross <jgross.biz(a)gmail.com>
*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
. 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
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.
keycloak-dev mailing list