Network effects and RPC
Mark Baker
mbaker@markbaker.ca
Mon, 9 Jul 2001 14:33:29 -0400 (EDT)
> http://frontier.userland.com/stories/storyReader$242
Why not do this as an HTTP POST?
It would be like this;
Arg #1, the title. Put it in a new HTTP header (or perhaps an existing MIME one -
would have to check).
Arg #2, the URL. Use the HTTP Content-Location header.
Arg #3, the text of the page. Put it in the HTTP entity body. Encodings
can be determined by Content-Transfer-Encoding feature, rather than by
Dave mandating use of base64.
Arg #4 and #5. New HTTP headers.
> I'd be happy to release the code that implements the interfaces.
>
> And you're totally right about the network effects.
I've thought about this, and I'm not convinced that RPC systems will see
network effects, at least not in the way Matt believes.
Network effects are generated by virtue of there being agreement made by both
ends. With the fax, the protocols and data formats were defined to implement
a single application, facsimile transmission, and both ends (being a fax
machine) agreed how to do this. With RPC, the only thing that's agreed upon
is what it means to do "invoke()". What kind of interesting things can be
generated by virtue of you and I agreeing what "invoke()" means? Not a lot,
I'd suggest. Now, if somebody built an RPC interface (let's say it's
Dave's search-submission interface), then perhaps *it* could generate
network effects if other search engines start implementing it, and people
start writing scripts and apps to submit URLs with it, but that says
nothing about how widely deployed somebody else's "Barney killing" RPC
interface is doing.
MB