cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: svn commit: r124693 - in cocoon/branches/BRANCH_2_1_X/src: blocks/authentication-fw/java/org/apache/cocoon/webapps/authentication /configurationblocks/axis/java/org/apache/cocoon/components/axis/provi ders blocks/forms/java/org/apache/cocoon/forms/eventblocks/forms/java/org/a pache/cocoon/forms/flow/javascript blocks/forms/java/org/apache/cocoon/forms/flow/javascript/v2blocks/for ms/java/org/apache/cocoon/forms/formmodel blocks/paranoid/java/org/apache/cocoon/servletblocks/scratchpad/java/o rg/apache/cocoon/components/flow/javascript/fom blocks/scratchpad/java/org/apache/cocoon/generationblocks/web3/java/or g/apache/cocoon/components/web3/impl java/org/apache/cocoon/components/flow/javascript/fomjava/org/apache/c ocoon/servlet
Date Sat, 15 Jan 2005 13:29:08 GMT
On Saturday 15 January 2005 04:32, Antonio Gallardo wrote:
> I am also planning to add Read/Write Object methods on some of this
> classes.

Serialization is often taken too lightly, and Sylvain and Vadim are both 
expressing this somewhat indirectly.

Serialization *must* be considered a public interface, IF you expect different 
versions of the application to co-exist with each other, OR that the 
serialized data is expected to survive from one version to the next.

The "public interface" aspect should then be viewed in the exact same light as 
a public Java interface/class, which Cocoon has plenty. You can not go about 
and change them friviously, even if the change doesn't break the Cocoon 
distro itself. Such changes are not happening, not because people can't do 
them, but because they know how it must be dealt with.
Serialization is not a technical problem, it is a people problem (just like 
the public interfaces) and the best guards against improper use, I think, is 
education, peer-review and tests.


View raw message