Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Robert Maas, http://tinyurl.co
December 1, 2010, 6:36 pm
rate this thread
http://TinyURL.Com/NewEco which is a new kind of economic system,
not using the dollar or any other official currency as a unit of
exchange, but not true barter either, since users won't directly
trade their services, but instead will perform labor for my system
to earn credits which they can then use to hire others. I'm hoping
eventually to have a billion people (everyone with cell-phone or
laptop/desktop computer) using my system, at which time this should
end poverty worldwide, thus ending the desperation that leads to
war and terrorism.
This system uses PHP/MySQL and CMU Common Lisp for various major
parts, plus some Unix applications written in C. Generally it uses
PHP/MySQL for the front-end, user account maintenance, and any
services that can be provided locally and are reasonably efficient
in PHP, and Lisp on Unix for anything that requires harvesting
content from the Web by parsing downloaded HTML pages, and
currently one C application for overlapping-rectangle
weighted-resampling of images to scale them for cell-phones. Lisp
is also used as client when covertly bootstrapping the public-key
parameters across an insecure link to remote PHP servers.
As a major part of the infrastructure of NewEco, I'm developing a
way to transfer public-key signed&encrypted SOAP-like messages
between different servers, such as between a PHP/MySQL hosting site
and my personal Unix account.
Until yesterday I didn't quite know what (standard jargon) to call
my system. I vaguely described it as similar to SOAP, but over HTTP
instead of a dedicated SOAP socket.
But yesterday I got curious about RESTful protocols and did a
search and found:
in particular the section comparing that with SOAP RPC over HTTP.
That protocol operates directly from client to server. The client
sends a SOAP message to the server, specifying a task to be
performed, and the server sends back to the client a SOAP message,
containing the response, i.e. what the user asked for, or an error
What I'm implementing is different in these ways:
- I probably won't be using XML as the primary format for
expressing structured data.
- Every SOAP-like message will be PK-signed by the sender then
PK-encrypted for the intended recipient.
- SOAP-like messages will *not* be exchaged between client (Web
browser) and server (PHP application), but instead will be
exchanged on a side channel directly between one PHP server
application and another. Client-Server HTTP GET redirection will
be used for the sending-server to transfer control to the
receiving-server and tell that receiving-server where to find the
message. The user will interact (via HTTP) with with the
sending-server before the transfer, then will interact with the
receiving server after the SOAP-like message has transferred
- Every SOAP-like request will contain two (or three) parts:
- A voucher telling how much of the user's funds have been put
into escroll to cover the cost of the service that is requested.
- The actual service request.
-optional- URL of a forwarding address (in case direct transfer
from user-account server to service provider isn't possible).
- Every SOAP-like response will contain two parts:
- Receipt showing how much of the voucher was actually spent (and
to which user's account it should be credited) and how much
remains to be refunded as "cash-register change" to the user
who made the request.
- The actual response listing the results of the user's request.
Details of the high-level design are here:
Planned implemetation (writing signed+encrypted message on hard
disk of PHP site, having Unix site do callback to fetch it, etc.)
not yet written up. Anyone who is seriously interested, especially
anyone wishing to critique my design and brainstorm improvements,
let me know, and I'll write up my current design plan. But hurry,
because I plan to start writing code in about 1-2 weeks from now.
So what should I *really* call this new kind of protocol?
The Subject field, which is rather verbose:
Public-Key Server-to-Server SOAP RPC over HTTP
Or has somebody else already thought of this kind of protocol and
has given it a better name?