<div dir="ltr">I see.<div>I was thinking of using one of the MessageReplayHandlers that require StorageService. There was only memcached based Storage Service, and was thinking of using redis instead. I think in this case serverside storage is required, unless you have any other suggestion?</div><div><br></div><div><br></div><div><br></div><div>George</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 17, 2016 at 7:59 PM, Jonathan Johnson <span dir="ltr"><<a href="mailto:jsjohnson@unicon.net" target="_blank">jsjohnson@unicon.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div 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 style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div 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 style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div><div 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><span class="HOEnZb"><font color="#888888"> <br> <div><div style="font-family:helvetica,arial;font-size:13px">-Jj</div></div></font></span><div><div class="h5"> <br><p>On August 17, 2016 at 19:27:46, Cantor, Scott (<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>) wrote:</p> <blockquote type="cite"><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 <a href="mailto:dev-unsubscribe@shibboleth.net" target="_blank">dev-unsubscribe@shibboleth.net</a>

<br></div></div></span></blockquote></div></div></div><br>--<br>

To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br></blockquote></div><br></div>