<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I’d like to highlight and emphasize something Scott says: avoid server-side storage.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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).</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div> <br> <div id="bloop_sign_1471488761421838080" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-Jj</div></div> <br><p class="airmail_on">On August 17, 2016 at 19:27:46, Cantor, Scott (<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On 8/17/16 8:06 PM, George Wang wrote:

<br>> Hi all,

<br>>  

> I see that we have support for memcached, but not Redis.

<br>> Do we have any plans on supporting Redis, or was there any decisions

> being made not to do so?

<br>

<br>We can't support every technology that comes along. We don't release

<br>things and abandon them without serious deliberation, so supporting

things is not free.

<br>

<br>Nobody involved with the project has any experience with Redis, or if

<br>they have, they haven't said so. If somebody interested in supporting it

<br>shows up to do the work and support/maintain the code, it will probably

get done. If not, probably not.

<br>

<br>My focus is on avoiding server-side storage altogether and there are

<br>very few use cases for non-persistent storage in Shibboleth that can't

be handled on the client.

<br>

<br>If we were going to spend real project time in the core team on anything

<br>involving state management at this point, I think it should be some way

to replicate webflow state.

<br>

<br>-- Scott

<br>--  

<br>To unsubscribe from this list send an email to dev-unsubscribe@shibboleth.net

<br></div></div></span></blockquote></body></html>