Thank you so much Scott. That is a really awesome answer, which also addressed some other questions in my mind.<br><br>Really appreciated.<br><br>Best,<br clear="all">Yaowen<br>
<br><br><div class="gmail_quote">On Tue, Jul 10, 2012 at 12:26 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 7/10/12 2:58 PM, "Yaowen Tu" <<a href="mailto:yaowen.tu@gmail.com">yaowen.tu@gmail.com</a>> wrote:<br>
><br>
>Per Scott's request, I am ask the question again in the dev list.<br>
<br>
</div>Thank you.<br>
<div class="im"><br>
>Can you explain a little bit more about this?<br>
> Nevertheless it is required because I don't have the luxury of<br>
>relying on<br>
>language-specific, proprietary session mechanisms.<br>
><br>
>I not quite sure that I understand this.<br>
<br>
</div>How would you propose to maintain a session for a web application if you<br>
can make no assumption about the application environment, language, or<br>
tools, and that consists of arbitrarily large data that needs to be kept<br>
protected from exposure?<br>
<br>
One option is to chunk, encrypt, and sign data into cookies. That is not<br>
generically feasible unless you assume the data size you're dealing with,<br>
or ignore clients of certain types, and it's complex and fairly<br>
inefficient in bandwidth and performance.<br>
<br>
The other option is server-side state indexed by a cookie or form field or<br>
whatever.<br>
<br>
Server-side state is impossible in most commodity web servers because<br>
they're multi-process. So you have to put the state somewhere. In the SP,<br>
it's in a storage service that is by default a memory cache in shibd. It<br>
can be in memcache, a database, or anywhere else a plugin sends it.<br>
<br>
Architecturally, it's possible to build the SP in a manner that relies on<br>
an external storage plugin, but runs everything that is normally in shibd<br>
in-process. That would obviate the need for shibd. The code can do this,<br>
apart from flushing out bugs I'm sure, it's just not something the build I<br>
maintain supports.<br>
<div class="im"><br>
>Also can you give me a small explain why you choose to implement SP in<br>
>C++ while IdP in Java? Is there any specific reason to do that?<br>
<br>
</div>Many reasons. I strongly prefer C++ to any other language. I can get more<br>
done in C++ than I can in languages I don't like or know well. It's also a<br>
lot faster without special effort, which means I can focus on writing code<br>
and not worrying about speed much.<br>
<br>
Most importantly, Java solves one problem, Java. With its fragmented<br>
security model, it doesn't have one integration strategy, so I can't even<br>
address every Java case with one solution. The same is more or less true<br>
of most Java alternatives.<br>
<br>
C++ solves problems for practically any web language because it works in<br>
Apache, IIS, and FastCGI. I'm not trying to solve every problem in the<br>
world, and I can't. I can solve more problems at once, as a single<br>
developer, using this approach than I can by writing in other languages,<br>
and at the same time I limit people to an integration model that, whether<br>
they like it or not, gives them the freedom to rip out my solution and<br>
plugin another. I value that more than I value locking in people with APIs<br>
in the guise of "better platform coverage".<br>
<br>
One of the decisions that comes up a lot is whether to invest time in<br>
wrappers that would expose what I did to other languages. The problem is<br>
that I don't perceive a willingness by such language adopters to accept<br>
native code. That's not a surprise since losing the ability to deploy "on<br>
top" of the stack with no root access or ability to install packages on an<br>
OS is one of the big drivers for those environments.<br>
<br>
Hope that answers some of your questions.<br>
<br>
-- Scott<br>
<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>