I've been playing around with some XML-RPC code in squeak 3.8g on my Powerbook.

First of all - any use ProtoObject that brings up the debugger causes
the problem with the image that was raised here about 3 weeks ago. I
don't recall seeing a resolution to that problem - does anyone know if
there was a fix? (ProtoObject works fine for proxies in 3.6 & 3.7, but
not 3.8 or 3.9 because of it).

As for the XML-RPC code, I wanted to see if I could come up with
something simple like the XML-RPC Python interface:

    from xmlrpclib import Server
    betty = Server("http://betty.userland.com/RPC2")
    print betty.examples.getStateName(41)

It seemed a shame that the XML-RPC interfaces I found for squeak all
seemed to avoid proxy objects, and instead relied on non-reflective
calls (like "req := XMLRPCRequest endpoint: url method: 'at:' params:
#('POR').").

Anyway, what I'm aiming for is something like the following on the client:

    proxy := XMLRPCProxy endpoint: 'http://127.0.0.1:8080/'.
    proxy at: 'POR'.
    proxy size.
    proxy at: 'DAL' put: 'Dallas Mavericks'.

or, if your talking to a non-smalltalk endpoint:

    proxy := XMLRPCProxy
        endpoint: 'http://betty.userland.com/RPC2' 
        translate: { #getStateName:->'examples.getStateName' }.
    proxy getStateName: 44.

On the server side I'm using a SwazooListener subclass (mmm, I like
swazoo) to wrap an object and delegate XML-RPC calls to it:

    server := SwazooXMLRPCWrapper new.
    server initializeWithPort: 8080.
    server wrap: nbaDict.
    server start.

The server code will automatically translate between Smalltalk-style
calls (<methodName>at:put:<methodName>) and non-Smalltalk-style
(<methodName>at.put<methodName>). This lets non-smalltalk XML-RPC
clients easily make calls to the wrapped object (e.g. from Python:
pythonProxy.at.put('PHX', 'Phoenix Suns'); )

It would be nice to make the translation done on the server more
controllable and take a translation list like the client proxy object
( ... translate: { #getStateName:->'examples.getStateName' } ) too.

The key principles I wanted to capture were:
  o Smalltalk to Smalltalk calls are the default setup
  o Translation tables are use if mapping is required
  o Client code should appear like a native method call via proxies
  o Server code should wrap any existing object, rather than requiring
a specific sub-class to be created.
  o Server objects use default translation to keep external clients
simple (e.g. Python & .NET via reflection)

I'm interested in what is the web-app most likely to suceed within
Squeak going forward - i.e. creating a stand-alone XML-RPC server is
easy via Swazoo, but what's the best way to hook it into an existing
web-app server?

Cheers,
Edouard.