From: Ken Paulsen <Ken.Paulsen_at_Sun.COM>
Date: Tue, 11 Sep 2007 13:35:13 -0700

-1

Adam Winer wrote:
> Ryan Lubke said the following on 9/11/07 1:08 PM PT:
>
>> [x] -1 Serialization of state in the server side case should be
>> DISABLED by default.
>
> -- Adam
>
>>
>> Majority rules.
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: [REVIEW/632] Server-side state saving sensitive to model changes
>> From:
>> Adam Winer <adam.winer_at_oracle.com>
>> Date:
>> Tue, 11 Sep 2007 12:39:45 -0700
>> To:
>> dev_at_javaserverfaces.dev.java.net
>>
>> To:
>> dev_at_javaserverfaces.dev.java.net
>>
>>
>> I'm fairly confident the spec says nothing. It also
>> does not say that server-side and client-side
>> state saving have precisely the same semantics - they
>> never have, not in 1.0, not in 1.1, and not now.
>> (They're closer in 1.2 than they were in 1.0.)
>>
>> I'm far from convinced this is a really important
>> compatibility issue, and suspect that requiring
>> serialization will in fact break some developers
>> that are (mistakenly) storing unserializable objects
>> on their components.
>>
>> In fact, I'm nearly certain that you'll break a lot
>> more applications than you'll fix.
>>
>> -- Adam
>>
>>
>> Michael Youngstrom said the following on 9/11/07 12:27 PM PT:
>>> I'm curious how this issue looks from a spec perspective? Does the
>>> spec imply or say anything to the effect that values stored in the
>>> view are isolated from change beyond that view? If the spec says
>>> nothing then lets look at this from the perspective of the next spec
>>> release. In the next spec release will we have a requirement for
>>> component developers to clone mutable values before storing them in
>>> the view? I would say no. I think that would be a confusing
>>> requirement to place on component developers. I know component
>>> developers right now are definitely not cloning mutable values placed
>>> in the view.
>>>
>>> I think compatibility, interoperability, and ease of component
>>> development should be the default over performance. This is the main
>>> reason why I think serialize should be on by default. If the user
>>> wishes they can turn this off to gain greater performance at the risk
>>> of broken functionality.
>>>
>>> So how do we make this decision? An RI group vote?
>>>
>>> Mike
>>>
>>> On 9/11/07, Ryan Lubke <Ryan.Lubke_at_sun.com> wrote:
>>>> Ed Burns wrote:
>>>>>>>>>> On Fri, 07 Sep 2007 11:32:22 +0200, "Jesse Alexander (KSFH
>>>>>>>>>> 323)" <alexander.jesse_at_credit-suisse.com> said:
>>>>>>>>>>
>>>>> JA> +1 from me too on not making the serialization default.
>>>>> Serialization is
>>>>> JA> way too costly.
>>>>>
>>>>> I cast my lot with Herr Jesse and Mr. Winer. I too would like to
>>>>> see a
>>>>> quantitative rationale, other than parity with the client side model.
>>>>>
>>>> Performance issues aside (which we know there will be a decrease in
>>>> performance
>>>> when this option is enabled), a JSF application should be have the
>>>> same
>>>> when using
>>>> the default state manager no matter what option is selected.
>>>>
>>>> For what it's worth, it seems MyFaces serializes server state by
>>>> default
>>>> [1]. So a SEAM
>>>> application on MyFaces will behave the same no matter the state saving
>>>> mode.
>>>>
>>>> I'm still torn on this issue. I think the correct course of action is
>>>> to enable the serialization by default,
>>>> but looking at the MyFaces benchmarks, performance is nearly halved in
>>>> this case and I really don't
>>>> know how often the case Mike is reporting will happen. Perhaps it
>>>> will
>>>> become more common
>>>> as more folks move to SEAM?
>>>>
>>>>
>>>> [1] http://wiki.apache.org/myfaces/Performance
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>