Packages (was: Re: DVS Roadmap)

Cees de Groot cg at cdegroot.com
Fri Nov 15 16:23:42 UTC 2002


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



More information about the Squeak-dev mailing list