This doesn't particularly relate to Webware, but I wanted to share the
idea with someone and it applies here...
Anyway, I was reading some article off /. about .NET, and then rereading
some stuff on REST:
And thinking about XMLRPC (I've never actually used SOAP, so articles
like this are all I know so far)... so I'm thinking about objects, and
how they can be represented in a neutral way. Obviously .NET has a lot
to say about this, but let's say we're not going down that path.
Now, you could say that objects were simple structs, maybe somehow
distinguished from XMLRPC <struct>, which usually have a non-object
analog (dictionaries, hash tables, associative arrays, etc). But then
that quickly is revealed to be trivial -- so why not just reuse <struct>
and add attribute access ontop of it. If why not, then why? Anyway,
it's the behavior of these objects that is much more interesting.
Then I thought about the fact that methods can also be considered
messages. Or methods can be considered instance variables, ala Python.
You just need a way of passing back references, maybe like:
The URL is an XMLRPC resource, which can take arguments like any other
resource. It's really just a URL, but if you look at it the right way
maybe it's much more powerful than that.
So, lets say we take struct and extend it. XMLRPC doesn't use
attributes much, but just this once let's do that, and imagine we're
publishing this object:
# published as http://www.parts-depot.com/parts/<id>
def __init__(self, id):
# probably get record from some database, etc
self.name = "widget"
self.description = "funny looking widget"
# fetch from database, return some other complex object
So when we get a part, we get a response like:
<value><string>funny looking widget</string></value>
Hopefully it's easy enough to see how this would be turned into a Python
object. The specification attribute would be an xmlrpclib.ServerProxy
object. "self" is implicit in the URL (/parts/3048), but that might not
be easy to implement with a lot of XMLRPC setups, where the URL points
to a script not an object. Anyway, maybe a notion of self could be
added to <method>. So, say /parts is the XMLRPC handler, and you passed
Then the result for specification might look like:
The contents aren't as important, as they would be handled by xmlrpclib
(or the language's equivalent) -- the result is a callable function,
equivalent to a bound method.
In this case, xmlrpclib would add the one <param> to be beginning of the
<params> list, and use the URL and methodName. If the server published
things more nicely via the URL, then some of this information could be
So, I'm sure these ideas exist in various RMI schemes, but I like that
this seems to fit XMLRPC pretty well, is language-independent, and
builds on a simple cross-language type system that already is widely
implemented (of course, as long as we add <method> and make this XMLRPC
incompatible, we should add <nil/> for good measure).
I might play around with object publishing in Webware using this... the
implementation seems fairly simple. Anyway, I'm interested in feedback
too, which is why I posted here in the first place ;)