dev@javaserverfaces.java.net

Re: [VOTE] [Fwd: Re: [REVIEW/632] Server-side state saving sensitive to model changes]

From: Jason Lee <jason_at_steeplesoft.com>
Date: Tue, 11 Sep 2007 15:24:19 -0500

-1

On 9/11/07, Ryan Lubke <Ryan.Lubke_at_sun.com> wrote:
>
> Let's make this formal...
>
> [ ] +1 Serialization of state in the server side case should be
> ENABLED by default.
> [ ] +0 Abstain
> [ ] -1 Serialization of state in the server side case should be
> DISABLED by default.
>
> Majority rules.
>
>
>
> 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
>



-- 
Jason Lee, SCJP
Software Architect -- Objectstream, Inc.
JSF RI Dev Team
http://blogs.steeplesoft.com