[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] s11n + rpc
From: |
Sean Doran |
Subject: |
Re: [Chicken-users] s11n + rpc |
Date: |
Sun, 13 Nov 2005 20:45:16 +0000 |
On 13 Nov, 2005, at 17:30, Zbigniew wrote:
I think you're describing a more complicated version of WRITE and
READ.
Well, yes, because that is fundamentally what s11n.egg's serialize
and deserialize are...
I was trying to be neutral in my wording, since I have no real love
of any particular flavour of markup language. Sexps or outright XML,
who cares, as long as I can be confident that when I serialize a
local object, it can be accurately (or at least reasonably)
deserialized in another chicken program at some arbitrary future
date, and on some arbitrary computer platform.
I know that the egg's version number is "0.2" and is more an
experiment to figure out whether arbitrary chicken objects can be
saved and restored at all. I do think it *is* cool that it can be
done at all.
Right now there are things like
(define (emitw w)
(display (word_to_bytes w) port))
and
(cond ((fixnum? x)
(emitb fixnum-tag)
(emit (fixnum_to_bytes x)))
...
and on the reading side
(switch tag
...
(fixnum-tag
(##core#inline "bytes_to_fixnum" (read-string +sizeof-word+ port)))
The result is a compact and computationally inexpensive binary
representation which is also both unsafe and unportable. (And also
hard to debug by eyeballing output or hand-generating input).
I think reading and writing a more platform-independent format should
be done by serialize / deserialize, rather than by other functions.
I offer two reasons.
Firstly, while filtering or wrapping would work, these other
functions would have to stay in complete sync with any change to
serialize / deserialize anyway.
Secondly, there is no platform, version or format identifier written
by serialize or checked by deserialize in 0.2. With no way of
knowing what wrote the data that deserialize is reading, and with
deserialize itself unable to cope with different endianness and
different word size, s11n 0.2 is a fragile egg.
So, yes, I am suggesting something more like WRITE and READ than s11n
is now.
On the other hand, I could be dead wrong for many reasons. For
example, the important uses of serialize / deserialize might end up
being ones that are sensitive to storage space, CPU time, CONSing, or
the like, instead of relying on long-term object persistence or
platform-agnostic distributability.
Sean.