[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))


(cond ((fixnum? x)
            (emitb fixnum-tag)
            (emit (fixnum_to_bytes x)))

and on the reading side

(switch 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]