Sanjiva Weerawarana wrote:
On Mon, 2005-10-31 at 16:56 -0800, Eric Johnson wrote:
The fundamental point, though, is that a bean need not have its own
serialization code - it can be "dumb" to how it actually gets
serialized. If you take that approach, the above question as to whether
you're using a "writer" or a "reader" might be moot. The generated(?)
serialization code can share gobs of functionality and perhaps do both.
The reflective serializers and deserializers do precisely this. Any
regular JavaBean can be dealt with this way but of course its slower
than if you codegen custom read/write code.
I must say I've not had time to look closely at the current
implementation, but if the plan is that the serialization code (either
codegen or reflection) exists outside the object in expected case, then
we agree on the substance, if not the actual details.
I still like an approach that uses a "writer", rather than a "reader" to
generate the XML. Two particular reasons come to mind:
* If the point is deferred creation of the XML, that probably also
means deferred reading of the state to be return in a response.
I agree that a writer is kinda natural, but this behavior makes me
wonder. When I say 'write this object' I don't think the expected
behavior is that the state gets snapshotted later, where "later" is an
undefined time.
Again we agree. My confusion, though, is if you return a "reader" for
an object, that data will be read at some later time. In order for the
behavior of least-surprise to work, you must snapshot all of the current
data for the reader. If that's what you're doing, then the "reader"
option doesn't buy you a smaller "footprint" - you have to cache the
data either way, either in XML format, or in clones of your original data.
All I'm reacting to is the idea that somehow using a "reader" will
reduce/defer serialization costs. In the end, I suspect it won't buy
any advantage. Caching all the data in a "binary" form so that an
XMLReader might later "read" it as XML might be just as complicated and
memory consuming as simply writing it to an XML format directly.
So I'd say its the *opposite* that developers would be expecting: that
the state that gets serialized is the state of the object when they
asked it to be serialized.
We agree on the ultimate behavior, apparently. Snapshotting the state
at the point of the serialization request, not at the point that the
data might be "read" from a "reader", or consolidated via a writer. I
guess I should go look at the code you've committed more carefully to
understand what you've done so far.
That argues for the current architecture.
Could very well be. As I said, I should go and look at the impl. Now I
just need to find the time.
-Eric.
