OpenRPC: user-attended RPC between sites

[Martin Atkins]

meepbear * wrote:
> 
> All that said, I didn't see anything wrong with OpenRPC :). It just
> seems preferable to make little changes to what's already there rather
> than start over with something new.
> 

I did read and have a think about the rest of your message, but I wanted
to reply to this bit. One of the most important things in my opinion is
that this becomes an application of OpenID, not part of OpenID itself.
This has a couple of advantages:

* If it turns out that it's better to do it some other way later, it's
easy enough to switch without hurting the core OpenID spec.
* The "RPC gateway" is decoupled from the "Identity server", which is a
fact that my demo relied on. It means that in cases where it makes sense
the software handling OpenID, profile exchange and weblog posting can
all be separate.

With all that said, I wouldn't have any objection to borrowing a
suitable existing RPC system and just adding the token exchange steps to
it, but as I was mentioning I don't think any of them are satisfactory:

* The idea here is that several standard RPC APIs emerge with given
functionality. For example, there would be a standard weblog posting API
which (hopefully) all weblog software would implement, allowing other
sites to be completely target-agnostic. My experience with XML-RPC is
that the function calls exposed by an endpoint are specific to the
application you are talking to. Even if a bunch of endpoints did
standardize, there's no globally-unique namespaces so there is a
possibility of collisions with existing functionality. Also, I've always
been frustrated with XML-RPC libraries as they always seem to want to
expose the application's internals directly rather than having an
RPC-specific layer in between.

* XML-RPC has a very rigid programming-language-like encoding, with
several place-based parameters of given fundamental types. The encoding
I chose for "OpenRPC", on the other hand, has the call arguments just as
an arbitrary XML nodeset, meaning that (for example) an AtomAPI entry
can be embedded directly into the posting API, which will then hopefully
allow existing AtomAPI code to be leveraged. I just took a quick look
and it seems that LiveJournal's AtomAPI would only need minimal
refactoring to be able to operate on an such an Atom entry. I would
argue that the entry processing rather than the request decoding is the
"hard part" that I'd want an existing library to handle: the basic
request decoding is trivial, really.

I guess I've written far too much here, though. As you're probably
beginning to guess, XML-RPC is the only one I really have any experience
with. I've toyed with SOAP a little, but I don't really know much about
it. If you can name something which addresses my two main concerns above
then I would be happy, since I'm not one for reinventing the wheel just
for the sake of it. I am, however, happy to abandon existing wheels when
they don't quite fit on my vehicle.