I probably should have vetted this before hitting send... let me know if
you need any clarifications.
Cheers,
Peter.
On 23/08/2019 12:59 PM, Peter Firmstone wrote:
"...since at the time the industry believed that distributed objects
were going to save us from complexity.) Many of the sins of
"...since at the time the industry believed that distributed objects
were going to save us from complexity.) Many of the sins of
serialization were committed in the desire to get that last .1%, but the
cost and benefit of that last .1% are woefully out of balance."
The following are probably
Hi Sean,
Regarding the section entitled "Why not write a new serialization
library?", unlike the serialization libraries listed, our purpose was to
be able to securely deserialize untrusted data, while maintaining
backward serial form compatibility with Java Serialization, provided it
didn't
Thanks Sean,
No I hadn't seen it, I've just read it, will probably need to read it
again to appreciate it fully...
It certainly identifies all the issues I'm aware of, as well as being
respectful of the original implementors (many of whom participated in
Apache River when Jini was donated
Brian Goetz (copied) has done a lot of thinking in the serialization
area, so I have copied him. Not sure if you have seen it but he recently
posted a document about some of his ideas and possible future directions
for serialization:
Thanks Sean,
You've gone to some trouble to answer my question, which demonstrates
you have considered it.
I donate some time to help maintain Apache River, derived from Sun's
Jini. Once Jini depended on RMI, today, not so much, it still has some
dependencies on some RMI interfaces, but
