You're welcome, thanks for asking :)
I'm proposing an API that allows for support and implementation of any
other serialization protocol (or combined serialization transport
layer), so all existing River Serializable classes would implement it,
to allow a standard method of access to internal
Thanks for putting the words here (again) for reference. Java Serialization
and the Web with MIME are so interlinked in time that it’s hard, sometimes to
think about the larger implications of interchange protocols that are transport
and language independent. We still pay a pretty large cost
Hi Gregg,
Yes, of course, if the service was using Java Serialization, the bytes
would be the same, but if a different Serialzation protocol was used,
the bytes would be different, appropriate for the serialization protocol
in use, these bytes would be transferred over existing transport
Can you speak to why it would be different than the stream of bytes that
existing serialization creates through Object methods to help clarify?
Gregg
Sent from my iPhone
> On Jan 29, 2021, at 3:46 PM, Peter Firmstone
> wrote:
>
> A question came up recently about supporting other
A question came up recently about supporting other serialization protocols.
JERI currently has three layers to it's protocol stack:
Invocation Layer,
Object identification layer
Transport layer.
Java Serialization doesn't have a public API, I think this would be one
reason there is no
