One final point: are we sure there is nothing in the current
design that forces users to make their code Serializable even when
using XStreamPageState? I just want to make sure that these sorts of
requirements don't creep into 1.0 and then it is impossible for me to
add XStreamPageState later on.
Also, I took a quick look at Session.java and there doesn't
seem to be a way to set the state to a different type (such as
XStreamPageState). You seem to initialize it internally and not give
external access to it. Are you saying I'd have to subclass Session with
XStreamSession that uses XStreamPageState internally and users would
have to explicitly set their Session to XStreamSession somehow (I don't
know that you can currently do that either)?
Gili
On Tue, 08 Mar 2005 12:26:38 -0500, Gili wrote:
>
> Fair enough.
>
>Gili
>
>On Tue, 08 Mar 2005 09:18:10 -0800, Jonathan Locke wrote:
>
>>
>>regardless, it seems like a good thing to test carefully in contrib
>>before moving into core. also, by implementing as an extension first,
>>we get to test out and ensure that our hooks for this sort of stuff
>>work. if it turns out to be as great as you say, i'm sure we'll all
>>discuss the possible core-ness of your contrib plugin in the future.
>>
>>i think one thing at a time here is best. xstream is definitely not a
>>1.0 feature (we have to ship this darn thing and the date keeps sliding
>>as people find more problems!). maybe contrib in 1.1. and then if that
>>works, it could be considered for core in 1.2. please note the word
>>"considered". we'd have to come to consensus. but the best way to get
>>that consensus is surely implementing an xstream plugin in contrib that
>>knocks our socks off.
>>
>>Gili wrote:
>>
>>> <sigh> I give up :)
>>>
>>> XStream is not "walking on the wild side". JSX, its predecessor
>>>has been around for *many* years and is a proven technology. XStream
>>>does the same thing, only it's free (the former was commercial). Both
>>>of these products simply hook into underlying JDK mechanisms to get at
>>>private fields, methods, etc. There is no native code or any magic at
>>>play here. Performance is very good.
>>>
>>> So fine, if all you want is a non-default contrib module then
>>>maybe we can start with that but honestly the kinds of arguments I'm
>>>hearing here from Chris:
>>>
>>>1) It's not good to add another JAR because it'll increase the size of
>>>Wicket
>>>2) Serialization requires "a certain discipline" which would be lost if
>>>we allowed XStream
>>>
>>> go smack in the face of Wicket's goals of focusing on ease of
>>>use before performance. No "discipline" is lost whether you use
>>>standard serialization or XStream. The same persistance rules apply
>>>(transient keyword, etc) whether you use one or the other. All we're
>>>doing is making it *easier* to serialize and if users want to come back
>>>and fine-tune the process further they can still do so. I think you
>>>guys are assuming (incorrectly) that XStream is "unstable magic" and
>>>that its performance is bad. Neither is true.
>>>
>>> I have compared XStream vs Serialization to Java vs C before. I
>>>honestly think it's that sort of thing.
>>>
>>> And Eelco, I'll work on the plugin as soon as I get around to
>>>working with Wicket again. Right now I'm knee-deep migrating to
>>>Hibernate3.
>>>
>>>Gili
>>>
>>>On Tue, 08 Mar 2005 09:00:04 -0800, Jonathan Locke wrote:
>>>
>>>
>>>
>>>>yeah. i'm +1 on that too. i'd also like versioning to be hookable
>>>>enough that you could replace cloning code with a contrib'ed version mgr
>>>>that uses xstream. best of all worlds this way. wicket would default
>>>>to the normal Serialization model, but then you could replace that using
>>>>contrib'ed xstream code if you felt like taking a walk on the wild side...
>>>>
>>>>Christopher Turner wrote:
>>>>
>>>>
>>>>
>>>>>My personal view is that we should not be including this as a standard
>>>>>feature of the core. It just adds extra jar dependencies, increases
>>>>>the size of the web application and so on. I'm personally more than
>>>>>happy with using the standard serialization mechanism provided by my
>>>>>application server vendor.
>>>>>
>>>>>Serialzation is a messy thing to deal with and I think that a certain
>>>>>discipline and design ethic is forced on you by having to implement
>>>>>Serializable and deal with the differences between transient and
>>>>>persistent fields. If you want to design efficient web applications
>>>>>then you have to be aware of the issues involved in this. Wicket can
>>>>>hide it for simpler applications but as soon as you start growing to
>>>>>servers supporting session clustering and recovery then you have to
>>>>>understand a bit more about what is going on and make some important
>>>>>design decisions.
>>>>>
>>>>>However, I would be +1 for providing XStreamPageState and other
>>>>>Xstream support as an optional implementation in the contrib package.
>>>>>
>>>>>Regards,
>>>>>Chris
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>if xstream doesn't have downsides and is more efficient and we don't
>>>>>>care about vm requirements, we could use xstream for undo cloning
>>>>>>operations. then if we provided XStreamPageState, you
>>>>>>wouldn't have to
>>>>>>make anything serializable. (uh... i think). xml seems like
>>>>>>a terribly
>>>>>>verbose format though. i'm concerned about memory impact...
>>>>>>
>>>>>>Gili wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>On Tue, 08 Mar 2005 08:32:18 -0800, Jonathan Locke wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>if gili wants to go test our new PageState mechanism by
>>>>>>>>
>>>>>>>>
>>>>>>making a nice
>>>>>>
>>>>>>
>>>>>>>>subclass of PageState using xstream (XStreamPageState?),
>>>>>>>>
>>>>>>>>
>>>>>>that might make
>>>>>>
>>>>>>
>>>>>>>>a really nice contrib or extensions class...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Before I do I want to make sure I have a better
>>>>>>>
>>>>>>>
>>>>>>understanding of how
>>>>>>
>>>>>>
>>>>>>>far I can go to serialize as little as possible with the web
>>>>>>>
>>>>>>>
>>>>>>container
>>>>>>
>>>>>>
>>>>>>>and handling the rest with XStream. My main concern is for
>>>>>>>user-classes: users should not have to worry about serialization or
>>>>>>>no-arg constructors and I simply want to give them the
>>>>>>>
>>>>>>>
>>>>>>option of doing
>>>>>>
>>>>>>
>>>>>>>so. So it would be nice if say we'd still have to persist
>>>>>>>
>>>>>>>
>>>>>>Wicket using
>>>>>>
>>>>>>
>>>>>>>the web container but everything else could be handled "in-house" by
>>>>>>>Wicket using XStream.
>>>>>>>
>>>>>>>Gili
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>-------------------------------------------------------
>>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>>Read honest & candid reviews on hundreds of IT Products from real
>>>>>>>users. Discover which products truly live up to the hype.
>>>>>>>
>>>>>>>
>>>>>>Start reading
>>>>>>
>>>>>>
>>>>>>>now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>>>>
>>>>>>>
>>>>><http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click>
>>>>>
>>>>>
>>>>>>>_______________________________________________
>>>>>>>Wicket-develop mailing list [email protected]
>>>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>-------------------------------------------------------
>>>>>>SF email is sponsored by - The IT Product Guide
>>>>>>Read honest & candid reviews on hundreds of IT Products from
>>>>>>real users. Discover which products truly live up to the
>>>>>>hype. Start reading now.
>>>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396
>>>>>>
>>>>>>
>>>>><http://ads.osdn.com/?ad_id=6595&alloc_id=14396>> &op=click
>>>>>
>>>>>
>>>>>>_______________________________________________
>>>>>>
>>>>>>Wicket-develop mailing list [email protected]
>>>>>>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>-------------------------------------------------------
>>>>SF email is sponsored by - The IT Product Guide
>>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>>Discover which products truly live up to the hype. Start reading now.
>>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>>_______________________________________________
>>>>Wicket-develop mailing list
>>>>[email protected]
>>>>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF email is sponsored by - The IT Product Guide
>>>Read honest & candid reviews on hundreds of IT Products from real users.
>>>Discover which products truly live up to the hype. Start reading now.
>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>>_______________________________________________
>>>Wicket-develop mailing list
>>>[email protected]
>>>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>>
>>>
>>>
>>
>>
>>-------------------------------------------------------
>>SF email is sponsored by - The IT Product Guide
>>Read honest & candid reviews on hundreds of IT Products from real users.
>>Discover which products truly live up to the hype. Start reading now.
>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>>_______________________________________________
>>Wicket-develop mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/wicket-develop
>>
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
