RFC: Apache2-JSONRPC && CGI-JSONRPC

[Tyler MacDonald <ty...@yi.org>]

Apache2::JSONRPC and CGI::JSONRPC have entered CPAN:

http://search.cpan.org/~crakrjack/CGI-JSONRPC-0.01/

It is an attempt to leverage the jsonrpc protocol (http://json-rpc.org) in
an object-oriented perl environment. It obeys the JSONRPC spec, with a perl
twist:

	* All requests pass the name of the object class we want to use as
the first argument, as is the perl way.

	* All responses are serialized as array objects, as perl return
values are arrays and not singular entities.

Using this package it's literally takes 18 lines of code to convert,
say, LWP::UserAgent into an AJAX-able component (ok, this isn't a
recommended practice but it's still damn cool):

perl-side:

        use LWP::UserAgent;
        package LWP::UserAgent;
        
        sub jsonrpc_new {
            my $class = shift;
            return $class->new(@_);
        }

javascript:

        Create_Class("LWP.UserAgent", "JSONRPC");
        LWP.UserAgent.prototype.get_page = function (url) {
            LWPer.Call_Server(this.write_page, "get", url);
        };
        LWP.UserAgent.prototype.write_page = function (result) {
            if(result._content) {
                this.frames[0].document.write(result._content);
            } else {
                this.frames[0].document.write("No content, result: " + result._rc);
            }
            this.frames[0].document.close();
        };


I welcome all comments, suggestions, and criticisms, and have a few
questions;

	- Apache::Test -- both CGI and mp2 are supported by CGI::JSONRPC. I
see it has a "need_cgi" method... what's the best way to implement
"need_modperl2"?

	- What's the best way to say "skip all tests if Apache::Test is not
available" on a per-testfile basis? Ideally I'd like to have some tests run
if Apache::Test did it's magic, and have other tests not care whether or not
that happened.

	- The goal of this package is to do things like CGI::Ajax, but in an
object-oriented way. It also strives to do as little as possible, so that
subclasses can decide how the archtectural framework is going to work as far
as persistance and serialization, etc. go. The specific naming of methods
etc aside, is this sort of thing appealing to anybody aside from myself and
the few deluded people I've been talking about this with in person? Is there
any other prior art I should be looking at?

	- (more directed towards the author, cc'ed in this email) JSON::Syck
is an XS package. I would like to be able to support storing what type of
object something is according to the JSONRPC protocol: see
http://rt.cpan.org/Public/Bug/Display.html?id=18081 and section #3 of
http://json-rpc.org/wiki/specification. Is this something that belongs in
JSON::Syck or should another class handle this?

	- If a camel was going to walk on stilts, would he choose to do so
in an anthropomorphic way, only on his hind legs, or would he need a pole
for each of his hooves?

	Answers to these and any other questions you think might burn me
appreciated.

	Thanks,
		Tyler