I've had good luck with NextStep classic plist format over the wire.  
Its dead simple.

Dictionary is { key = value; key2 = value2; }
List is ( one, two, 3, "four or more\nsecond line", five )
Strings are simple if they are just tokens (no whitespace or 
punctuation) or like C-style string literals otherwise.

Combine elements in any combination.  Dead easy to write a parser too 
(I have one in java if anyone wants it).  Probably do one in Squeak 
pretty soon unless someone can point me to a better serialization 
format already there.

On Friday, November 15, 2002, at 05:23  PM, Cees de Groot wrote:

> Ned Konz <ned at bike-nomad.com> said:
>> * XML is hardly simple. I don't want to be tied to having XML in an=20
>> image just to be able to communicate with an external repository.
>> And the amount of code required to support XML/RPC (or SOAP or=20
>> whatever) is not trivial.
>>
> Well, for all purposes and compared with the junk the XML community is
> churning out, I think XML/RPC is at least *relatively* simple ;-). I 
> use it a
> lot to hook up VisualWorks to, say, some Perl CGI scripts, etcetera. 
> Maybe
> it's the wrong thing for homogeneous Sq-Sq communication, but it has 
> the nice
> property that you can even cobble up a simple client in a shellscript 
> so
> you're not pinning yourself down on Sq-Sq comms.
>
>> * Why would XML/RPC (presumably over HTTP) to another Squeak be 
>> better=20
>> than HTTP PUT or POST to another Squeak?
>>
> XML/RPC was just a suggestion, I'm certainly not hooked to it (but
> nowadays, because there's no escaping the thing, I sorta assume that
> some XML parser is always around to take care of other business, so
> that would make XML/RPC a lightweight addition; that may be a wrong
> assumption, indeed).
>
> The advantage is that you can easily marshall/demarshall data between
> anything that understands strings/numbers/arrays/hashes (say the basic
> Perl arsenal of data types), i.e.  it doesn't cost too much application
> code (just convert your objects to a nested structure of these 
> primitive
> data types and let XML/RPC handle the rest), and because XML/RPC 
> doesn't
> need all the funky XML stuff they keep inventing, a complete braindead
> XML parser (say, like the one that is included in the Python standard
> libs) can read and write the format. And the code is there (for VW,
> but I think it's easy to port if it hasn't happened already; I'll be
> happy to volunteer). With XML/RPC you'd have your write protocol, 
> simple
> marshalling/demarshalling routines (and I'm sure you can remove most 
> of that
> with a little bit of metaprogramming), a quick path to a reference
> implementation with client and server in Squeak, but without cutting of
> efforts at alternative server implementations.
>
> Whatever works, is simple to implement, and relatively 
> reliable/secure. It's
> just a suggestion...
>
>
> -- 
> Cees de Groot               http://www.cdegroot.com     
> <cg at cdegroot.com>
> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD  1986 F303 937F E098 9E8B
> Cogito ergo evigilo
>