Redis support for StorageService in opensaml-java?

[Jonathan Johnson]

I’d like to highlight and emphasize something Scott says: avoid server-side storage.

As someone that works with server-side storage (and has written an implementation or two), chances are that you really want to use client side. It’s a lot more scalable, and for most people, sufficient. I don’t like to get into the details of why one might like to use server-side because it often elicits the “I need that!” phenomenon. In the several deployments of v3 that I’ve done, only a few have needed server-side, and most of those because of the CAS protocol support (and once that goes stateless, I’ll try to move those folks off server-side).

As another note, it might help the developers if you could identify why you might want to use a server-side storage, and perhaps they or someone from the community might help find a good fit.

-Jj

On August 17, 2016 at 19:27:46, Cantor, Scott (cantor.2 at osu.edu) wrote:

On 8/17/16 8:06 PM, George Wang wrote:  
> Hi all,  
>  
> I see that we have support for memcached, but not Redis.  
> Do we have any plans on supporting Redis, or was there any decisions  
> being made not to do so?  

We can't support every technology that comes along. We don't release  
things and abandon them without serious deliberation, so supporting  
things is not free.  

Nobody involved with the project has any experience with Redis, or if  
they have, they haven't said so. If somebody interested in supporting it  
shows up to do the work and support/maintain the code, it will probably  
get done. If not, probably not.  

My focus is on avoiding server-side storage altogether and there are  
very few use cases for non-persistent storage in Shibboleth that can't  
be handled on the client.  

If we were going to spend real project time in the core team on anything  
involving state management at this point, I think it should be some way  
to replicate webflow state.  

-- Scott  
--  
To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160817/064c5a56/attachment.html>