Hi all,
as I am also interested in short term serialization just for moving objects
between a distributed virtual machines and not in long term serialization, I
would support the discussion up to now. To express our intentions we could
make an interface, say
public interface Transportable extends Serializable { }
and then implement this interface when ever containers should be short term
serializable. This interface could then also document our intentions. And this
would then allow the usage of CM in a distributed setting.
Regards,
Heinz
Am Mittwoch, 9. Mai 2012, 09:03:20 schrieb Luc Maisonobe:
> Hi Gilles,
>
> Le 08/05/2012 23:05, Gilles Sadowski a écrit :
> > On Tue, May 08, 2012 at 02:55:47PM -0400, James Carman wrote:
> >> I don't know that you want to get into supporting long-term
> >> serialization support. I would say CM should support transient
> >> serialization (if that makes any sense), such as
> >> marshalling/unmarshalling. If you guarantee long-term serialization
> >> support (reading data from serialized for much later, perhaps by
> >> another version of CM), then we get into the nasty serialization test
> >> cases like Commons Collections has/had. Yuck!
> >
> > That's the question: What does it mean to support serialization?
>
> It can mean many things. However, I thought we concluded last time that
> what [math] would not attempt to support long term serialization, i.e.
> reading again old versions. So we basically ruled out cross-version
> support based on SerialVersionUID.
>
> > Is there such a thing as short-term serialization?
>
> Yes, of course, and this what many people need. This is what James
> called marshalling/unmarshalling. This is a standard way to communicate
> between some applications that share a common basis. Of course [math] is
> not a distributed computing environment, but it should not prevent
> people from being used in a distributed environment.
>
> > CM's purpose is not distributed computing. A project could exist with
> > that purpose, and it would indeed choose the "best" possible library to
> > provide the "distribution" functionality. People on this list already
> > said that it should not be the standard (original) Java serialization
> > mechanism.
>
> And other people said there is a trade-off between a perfect library for
> this and a library that is cumbersome for people because it does not
> even provide the most basic serialization process for simple containers.
>
> I will take care of this issue, and will try to do this as cleanly as
> possible.
>
> Luc
>
> > Regards,
> > Gilles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
