That's exactly what we saw in the Mac market, this is how apps turn into
platforms. Every app developer wants to blaze their own trail. You could try
saying "there's a better way to do it" but that just creates noise and
confusion, much better to just let them do what they want. At least Evan is
re-using major portions of working code that will make it relatively easy
for scripters to write the connecting glue between environments and his app.
That's all that's required to get a developer community going.

IDLs wouldn't help much -- that's just another layer to debug or fail to
debug. And the human beings involved in the loop are helping him, no IDL can
offer advice or feedback in realtime. One of the big mistakes people make is
to think that humans are not needed in creating the glue between apps and
environments. My experience is the opposite. If a community doesn't form at
the intersection of an app and an environment, nothing happens there.

We're going to do some of that work for Blogger, for free, because Evan gave
us an incentive to do it, by using XML-RPC he aligned with a community that
now has an investment in his success.

Perhaps the P in XML-RPC stands for People, too. ;->

Dave


----- Original Message -----
From: "Julian Bond" <julian_bond@...>
To: <decentralization@yahoogroups.com>
Sent: Monday, August 13, 2001 1:26 AM
Subject: [decentralization] RPC vs CGI, RPC vs REST


> In article <0b5e01c12397$117fb320$33a1dc40@murphy>, Dave Winer
> <dave@...> writes
> >PS: Evan added three more methods to the Blogger API today.
>
> Here we have an example being played out right in front of us. I wonder
> if it can tell us anything useful about the merits of RPC?
>
> On one side we have a centralized service that's acting as a gateway to
> many instances of websites. It always had a CGI interface that can be
> called from code (there's an example of this being used at
> http://www.newsisfree.com). Now it's got an RPC interface to the same
> function.
>
> On the other side we have a client side app, with a scripting
> environment that knows how to call XML-RPC. It's already got code that
> implements calls with very similar function but to a 3rd system that has
> already implemented RPC.
>
> Discovery
> - The only way to find out about the Service was out of band. (Via html,
> email, RSS).
> - The service documentation is on a web page. The web page versioning is
> behind the implementation versioning as it only mentions one method.
> There may be a machine readable IDL file but it's not obvious where it
> might be.
>
> Security
> - Right of access is out of band. In this case, by emailing the service
> owner. I'd expect this to be common, wherever access control is an
> issue. Maybe it will be a web form instead of email, but it'll still be
> out of band.
> - The system needs a pre-existing ID and password to work. These get
> sent in plain text, but then the normal CGI interface also uses plain
> text with no SSL. If this had been an issue, there are plenty of well
> understood methods to protect it.
>
> Additional function over CGI
> - Structured return error codes. The RPC interface returns structured
> errors. CGI returns errors but unstructured in a web page. With
> knowledge of the layout, you could always parse the page to find them.
> But why should you have to?
> - Structured return data. The system returns a reference ID. Again, CGI
> could do the same, but it would be unstructured and harder to work with.
> The first implementation of a call to the service uses the returned data
> to do something useful.
>
> Maintenance
> - The Service is statically defined and a change in the interface or
> location of the end point will break implementations that use it. The
> web page documentation specifically warns that the end point might move.
> - The Service uses ordered, un-named parameters. All of which are
> required. If the sequence or number of parameters changes, calling
> systems will break.
>
> So. This all looks remarkably like the sort of issues that are going to
> turn up repeatedly if web services take off. To me, there is a big gain
> over CGI in the formal structuring of the returned data. Pretty much all
> the points (criticism?) I've raised have been dealt with in other RPC
> calling conventions or Service implementations. But the whole system was
> easy enough to implement that a reference call was put together in a few
> hours. Some more formal definition of the interface and end point might
> have made this easier and more resilient to future change but html got
> the job done.
>
> But to answer Clay, even though there are great similarities between
> manila.homepage.addToHomePage and blogger.newPost() both in function and
> raison d'etre, it's really hard to see how any system built to work with
> the first could automatically start working with the second. Though MS
> does have some initiatives (biztalk) to build an index of mappings
> between functionally equivalent web services. But I bet "functionally
> equivalent" is going to be a pretty hard call in most cases.
>
> BTW. My apologies to all concerned if I've inaccurately summarised the
> issues or details of either implementation.
>
> --
> Julian Bond email: julian_bond@...
> CV/Resume: http://www.voidstar.com/cv/
> WebLog: http://www.voidstar.com/
> HomeURL: http://www.shockwav.demon.co.uk/
> M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433
> ICQ:33679668 tag:So many words, so little time
>
> To unsubscribe from this group, send an email to:
> decentralization-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>