Ed Burns wrote:
>>>>>> On Wed, 12 Sep 2007 09:10:36 -0600, Michael Youngstrom <youngm_at_gmail.com> said:
>>>>>>
>
> MY> So, the the votes are in and it looks like the decision is to not
> MY> serialize the server state. However, does this snippet from the spec
> MY> make our vote irrelevant?
>
> MY> Section 7.6.3: when talking about server state management says:
>
> MY> "The default implementation Serializes the view in both the client and
> MY> server modes. In the
> MY> server mode, this serialized view is stored in the session and a
> MY> unique key to retrieve the
> MY> view is sent down to the client. By storing the serialized view in the
> MY> session, failover may happen using the usual mechanisms provided by
> MY> the container."
>
> MY> It seems pretty explicit here. This is probably why Myfaces
> MY> serializes the view by default in "SERVER" mode. Does this snippet
> MY> from the spec change our decision at all? If we decide to ignore this
> MY> snippet of the spec we should probably let MyFaces know so that they
> MY> don't have to serialize the view by default.
>
> Ah yes, I recall now why we put that in there. It was to guarantee that
> failover would work in clustering server scenarios.
>
This works as it is now without serializing the data to the session, as
long as developers
are aware of the rules surrounding storing data in the HttpSession.
> I propose we modify the spec to introduce a config param that turns it
> on, but have it off by default. Should I take that to the EG?
>
> Ed
>
>