--- begin forwarded text


Status:  U
Date: Mon, 25 Mar 2002 23:03:13 -0500 (EST)
From: Ian Grigg <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [dgc.chat] XML/X - part I
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]

It is with some satisfaction that we announce the first
public demonstration of a new project that we've been
working on for the last six months.

This demonstration is taking place at Java 1 this week,
by Erwin Van der Koogh, a programmer with Sun's XML group
in Dublin.  He's also a WebFunds programmer, having been
primarily responsible for the current generation.

You can check out a scratch home page for the project at:

       http://www.webfunds.org/guide/xml/

We were looking some time ago at the difficulty faced
by the various merchants in implementing access to the
current money providers.  As no merchant could really
predict where the good money was, so to speak, it was
pretty obvious that being able to implement a range of
gold-based units was much less risky.

But it was also rather impossible.  The transfer methods
for the systems ranged from pretending to be a browser,
to accessing partially complete protocols to .. nothing.
None of the systems in place seem to appeal as none of
them have actually been thought out from the point of
view of what we know about protocols and networks.

It behoved us to come up with our own spend system.  We
were in the throes of developing our own web-based system,
and we wanted that bit right.  After all, a lot of demand
comes from the support of the merchant class (a group we
christened as Matildas, but that's a story for another
day).

Others, such as Intertrader, were still smarting at the
cost of having developed access for different systems,
and not having been able to efficiently deploy it because
of the system bugs imposed on them.  And, yet others
simply didn't know where to start.

It all begged for a standard.  We sat down and drew one
up.  Now, because standards committees tend to be noisy,
rumbunctious, and ultimately unproductive, unless they
have a *very* solid mission to draw from, we decided not
to make this a publicity thing in the beginning.  That
is, we decided to write it first, then open it up.

All well and good, and of course, we chose to do our
transfer interface in XML.  We called it XML/X as a
quick code name for the project, being transactions in
XML.  The results will be open source, the documentation
will be readily available, and no fees will be levied on
joining or using.  Even though this project is about
money, it makes more monetary sense to impose no barriers
on its widespread adoption.

A quick example might clarify what all this hyperbole is
about.  Imagine you have some accounts at a standard DGC
such as e-gold, goldmoney, or one of those other systems
such as PayPal.  As a merchant, you want to initiate a
transaction from your automated web system to pay out a
customer.  Or vice versa.

So, you open up a connection to the money server and
send down a stream of commands to cause it to happen.
Here's how you would do it in today's XML/X:

     <TransferRequest>
       <Transfer>
         <ClientID> P9348235 </ClientID>
         <Payee> E3491 </Payee>
         <Payer> 34201-543 </Payer>
         <Amount> 45.23 </Amount>
         <Currency> Platinum </Currency>
         <Memo> Slicker than Slick </Memo>
       </Transfer>

       <Auth>
         <Username> iang </Username>
         <Password> Rock On </Password>
       </Auth>

     </TransferRequest>

(Take that as an alpha - it's still evolving and is
likely to change.)  Consider this one feature as an
example:  In our XML/X, you can do a one-shot transfer
and get a reliable result.  It's reliable because you
can resend it (see the <ClientID>?), and get the same
result - one and only one transaction, as long as the
server saw the instruction and acted at least once.

That's pretty useful.  In fact, it's so useful it
is blessed with the otherwise indecipherable term of
_idempotency_ (which means, it happens zero times or
once, no matter how many times you send it).  There are
lots of other useful features, but they lack general
interest unless one has social disabilities and wears
a propellor.

How useful would all that be to a cambist?

Such near-latin would be even more useful if all systems
offered the same interface.  By designing in elements
of protocols, it makes sense to adopt this one rather
than roll your own.  As an aside, XML/X incorporates
elements from SOX, the most reliable protocol for money
I've ever seen, although I admit to being a tad biased.

But the best is yet to come...

TO BE CONTINUED...

Send email to <[EMAIL PROTECTED]> with the word Help
in the body of the message for help with list subscription.

--- end forwarded text


-- 
-----------------
-----------------
R. A. Hettinga <mailto: [EMAIL PROTECTED]>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA

The IBUC Symposium on Geodesic Capital
April 3-4, 2002, The Downtown Harvard Club, Boston
<mailto: [EMAIL PROTECTED]> for details...

"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---
You are currently subscribed to e-gold-list as: archive@jab.org
To unsubscribe send a blank email to [EMAIL PROTECTED]

Use e-gold's Secure Randomized Keyboard (SRK) when accessing your e-gold account(s) 
via the web and shopping cart interfaces to help thwart keystroke loggers and common 
viruses.

Reply via email to