You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most IdentityProviders are self-contained, only depending on bits and pieces of Play.
I propose breaking out the self-contained parts of module-code out into a securesocial-core, then abstracting the bits of Play that are actually required (configuration, HTTP, caching, localization) into adapters that can bridge the gap from different versions of play (and different libraries entirely).
Given the recent 2.1.4-for-play24, it seems like this will become more important as Play continues to evolve, since specialized adapter code would be able to be defined in the consumer's project, the different versions of securesocial-core being versioned completely separate from Play.
This is just a proposal, I'm curious to see how many would be interested in something like this.
The text was updated successfully, but these errors were encountered:
@blast-hardcheese I thought of this several times and it was even proposed in the mailing list if I remember correctly. I need to wrap up the new version which is quite delayed and then see if/how this could be done.
@jaliss Definitely understandable; I haven't had nearly as much time as I thought to work on it, although I've continued attempting to write these generic abstractions (recently working in shapeless, which gave me many new ideas)
I'll probably have more time to work on it closer to the end of February, but I'm sure that's too late.
Is it a problem to release a new version, then release the generic stuff later? Or are you needing to support many versions of play?
@blast-hardcheese I would not include a refactoring like that at this point. There are other urgent things so this is really something for a future version.
Most
IdentityProvider
s are self-contained, only depending on bits and pieces of Play.I propose breaking out the self-contained parts of
module-code
out into asecuresocial-core
, then abstracting the bits of Play that are actually required (configuration, HTTP, caching, localization) into adapters that can bridge the gap from different versions of play (and different libraries entirely).Given the recent
2.1.4-for-play24
, it seems like this will become more important as Play continues to evolve, since specialized adapter code would be able to be defined in the consumer's project, the different versions ofsecuresocial-core
being versioned completely separate from Play.This is just a proposal, I'm curious to see how many would be interested in something like this.
The text was updated successfully, but these errors were encountered: