[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Auth]technical details
From: |
Ron Burk |
Subject: |
[Auth]technical details |
Date: |
Fri, 27 Jul 2001 10:54:39 -0700 |
I have also updated my examples to take into account the
feedback on the list.
* Possibly useful to allow the web site to supply the value of a
data field in its "request". Idea is that sophisticated web sites
could make initial sign-up highly transparent by handing the
client his new account name (and/or other information that
is generated by the web site -- some sites will assign you a
password, and that option becomes more appealing when
there's a framework in which the customer never has to see
or type the password). This is for web sites that can dynamically
generate the appropriate .gnu file.
Another case is when the web site already has your credit
card information on file, and they just want to confirm whether
or not it's still accurate.
* There's a semantic difficulty in the fact that you've started
describing a database, besides an interface for requesting
information. The former is both more difficult, and may unnecessarily
constrain vendors, who already have their database designed.
For example, the typical web site just wants to ask for "Credit Card".
But the personal information database will want to allow for
multiple credit cards, each of which the user can assign a mnemonic
name (a name not at all visible in the information request space).
Same story with addresses, and even names.
* I think(!) I understand the motivation for making a hierarchical
namespace of field names. However, I would feel better if the
web site could still just use a flat namespace. Most web sites
just want "Password", for example. Most web sites don't
necessarily want to specify what kind of "address" you should
give them. The major exception being when they want to specify
that the address should be identical to the billing address for
a given credit card.
* Speaking of having the web server supply data to the client,
perhaps its useful to allow inclusion of a comment field,
for the client software to optionally use to describe why the
web server is asking for this.
The request interface seems to be rapidly getting to the
point where the vendors of the actual client software need
to be involved (the folks who already have complete databases
implemented, and must be sold on the idea for it to succeed).
Let us say the web site redirects the client software
to the following URL:
x-dotgnu://localhost/<request-info>
the browser will invoke the installed x-dotgnu
protocol handler to handle the URL and will display
any content output by the protocol handler.
Interesting technique (meaning, I bet I can find a
use for it on some project or another :-). Thanks for
the additional description.
Ron Burk
HighTechInfo.com, www.hightechinfo.com
- [Auth]technical details,
Ron Burk <=