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

[Pedro Igor Silva]

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 at 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.
>
>
>
> 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 at redhat.com>
> *Sent: *Monday, June 10, 2019 8:03 AM
> *To: *Justin Gross <jgross.biz at gmail.com>
> *Cc: *keycloak-dev at 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 at 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 extremely useful.
>
>
> Thank you,
>
> Justin Gross
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>