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