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
