The 'special interface' would break schema based serialization such as GPB as well as other byte-stream based libs such as Jackson, so I'd rather go with a registry of type serializers or something like that. More as soon as I'll get a better keyboard :)
My 2 euro cents, Cheers, Sergio Bossa Sent by iPhone Il giorno 26/mag/2010, alle ore 18.46, Geert Bevin <gbe...@terracottatech.com > ha scritto: > I read through the Hazelcast docs to see how they do it. They > basically require each type to implement Serializable, but it can > also implement DataSerializable instead, which provides a more > efficient way of serializing by giving direct access to DataOutput > and DataInput types. This provides methods to write/read literal > types directly instead of converting an entire object into a byte- > array. These makes a lot of sense since data classes are typically > an aggregation of strings, collections, numbers. These can be > handled directly by the toolkit without using byte array > serialization. > > I think we could keep this in the back of our heads as a possible > solution for a future version and detect also on the interface that > the data implements that is stored into a toolkit collection. > > Thoughts? > > On 26 May 2010, at 08:28, Alex Snaps wrote: > >> Don't mean to hi-jack this thread, but I wanted to continue on custom >> Serialization mechanism to go beyond Java Serialization capabilities, >> that we discussed in this meeting: >> I didn't like the decorated data structure approach so much, for the >> same reasons as Chris mentioned. >> Thinking slightly more about it, I'd much rather like some JCE kinda >> mechanism, where one could register Serialization mechanism >> cluster-wide. When data get serialized it would also be signed so >> that >> the proper strategy to deserialize the stream can be automatically >> selected. >> Now that raised the question about the default mechanism to use and >> possibilities to override it depending on the data structure's >> instance or even usage. >> So I guess instance-wise, a constructor argument could register the >> strategy with the mechanism and with the global registry (unique >> identifier). >> If there is a requirement for usage-based strategy (different >> strategies in the same instance), we could fall back to decorating >> e.g. the Map, so that all entries added through that decorated >> instance would use another serialization mechanism... Now, would we >> need to track (instance- or, for maps, key-based) what strategy to >> use >> overtime? >> This all of course doesn't answer the question when this >> Serialization >> is to happen. >> Something in that direction could then also probably ease version >> transitions on stored Object. >> >> Just wanted to get this out of my head and shared, even though I >> think >> this is less relevant now, given how I understood the discussion >> ended. >> Alex > > -- > Geert Bevin > Terracotta - http://www.terracotta.org > > _______________________________________________ > tc-dev mailing list > tc-dev@lists.terracotta.org > http://lists.terracotta.org/mailman/listinfo/tc-dev _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
