[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: Sat, 12 Nov 2005 14:48:54 +0000

On 12 Nov, 2005, at 13:58, felix winkelmann wrote:

I'm not sure how to proceed, though.

One approach would be to translate the binary output into a tagged/ marked-up format like *gasp* XML...

A sender would do something like write a tagged/marked-up (number- >string n). What a receiver does with such a number too large or too small for its native fixnum is up to it.

#;1> (string->number "230984203849023894")
#;2> (use numbers)
; loading /usr/local/lib/chicken/numbers.scm ...
; loading /usr/local/lib/chicken/ ...
#;3>  (string->number "230984203849023894")

On the other hand, a markup language could tell the receiver that it must maintain a certain precision or fail. Who knows what could evolve?

Platform-independent serialization opens up a lot of possibilities - on the other hand the serialization of procedures is highly dependent of the compiler version and even optimization options...

You could keep the scheme source around and serialize that... That presents lots of work for the receiver, but a memoization approach could avoid recompilation of already-received procedures. This seems to call for a globally unique ID for the serialized procedure, and could be optimized with an ihave/sendme kind of dialogue.

s->r:  i have someprocguid
r->s:  i don't, so send it
s->r:  <serialized procedure>

receiver may save the serialized procedure and its own compiled version of it for future use, so that later:

s->r: i have someprocguid
r->s: i have it already

and thereby save the work of processing a serialized procedure.

This approach could be used for any serialized object, not just procedures.

Finally, using a globally unique id has advantages in terms of allowing for persistence and distribution.


reply via email to

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