SWF / MVC write-up

[Brent Putman]

On 9/4/13 11:27 AM, Cantor, Scott wrote:
>> We could move the testbed to svn.shibboleth.net or maybe Brent could
>> open his up somehow, but I was hoping to make idp-distribution
>> worthwhile for testing. Let me know which you prefer.
> I just think we need something, and it definitely needs to be usable like
> Brent's is, maven jetty:run with the web context loaded from the project
> tree directly.

Tom sent me a note earlier asking if we could move java-shib-testbed to
svn.shibboleth.net.  Like I said on the call a few weeks ago, that's
perfectly fine, we just need to decide a place to put it.  IMHO it
shouldn't really be a part of the IdP codebase, nor is it really an
extension or utility.  So maybe it should just be a (presumably
temporary and transient) repo all unto itself?

>
> The fundamental issue is the context tree, as I just responded to Marvin.
>
> But I should note that we don't have the freedom to impose Serializability
> on things. That's really the essence of the matter: can we put things into
> the context tree we don't control? Right now we can. If we Serialize, we
> can't (I don't think requiring creation of external serialization code any
> time something new is needed is practical).

Yes, and also not to mention that implementing (and testing!)
Serializable for everything in our own codebase (that could appear in
the context tree at least) is a massive amount of work and would I think
easily become the single biggest work item left on the TODO list for
v3.  That was one of the big reasons it was a non-starter for Chad, at
least.

The other is that apparently Java Serializable is viewed by many as a
Bad Thing(tm). Chad was very opposed to implementing Serializable on
that basis as well. I was skeptical of this reason initially. However, I
saw Joshua Bloch (notable designer of many things in the Java platform
itself and respected software engineer) speak once at OSCON about
language/platform features that have been added to Java since the
initial language design; his opinion was that Serializable was the
single worst mistake they had made (up to and including Java 7 stuff). 

The other potential approach is external serialization.  As Scott says,
requiring a slew of external serializers to be written and registered
was also seen as non-viable, especially for the third-party stuff, and
was the main reason that we wound up rejecting Infinispan as a
clustering technology. In that regard it was similar to Terracotta,
which requires you to declare all of the instrumented classes on the
heap.  


> Related to this, we can't OOB put objects into view-scope that aren't
> Serializable (again unless we provide our own code to do that). But that I
> was able to come up with a possible work-around for.


On view scope stuff specifically:  Admittedly I don't have a lot of
hands-on with this, but my expectation all along has been that you
wouldn't just stuff the entire context tree into the view scope.  You'd
put the specific things that that particular view needed into the
scope.  That's consistent with how MVC usually works; in a controller
you don't stuff every object you know about into the view, you just
expose the specific model data that the view is rendering.  Maybe we
have more complex cases where that usual assumption doesn't always hold,
though.