Re: [Auth]I claim simplest design of all time!

[Jeremy Petzold]

How about  /. and source forge?


--- Albert Scherbinsky <address@hidden> wrote:
> I like it. ( I've been lurking on the list till now,
> but
> this sounds good. :) 
> What is really needed then is marketing assistance
> in the
> form of a nice web page that promotes the vendors of
> form
> filling software giving end users a place to find
> the client
> software and a list of web sites that use the dotGNU
> standard.
> 
> So, how do you convince the vendors to cooperate?
> One
> strategy might be to find a large web site that is
> willing
> to adopt the dotGNU standard, then this represents a
> large
> pool of potential customers for the form filling
> software
> companies. :)
> 
> This does not preclude someone writing one and
> applying the
> GPL to it.
> 
> Albert
> 
> Ron Burk wrote:
> > 
> > >Perhaps such an article could also be published
> in Windows
> > >Developers Journal?
> > 
> > I don't work there any more, but I possibly am of
> some
> > use in getting press in some developer media
> venues.
> > 
> > >I have written a proposal sheet for the simplest
> solution I can imagine,
> > >which is extendible enough for future use.
> > 
> > I was determined not to beat this horse again, but
> this got me going.
> > The simplest solution *is* extendible because it
> assumes
> > nothing about the future except that you will need
> standard
> > names for data fields like "Name", "Account",
> "Password",
> > and so on. Does anyone doubt that assumption?
> > 
> > If you're willing to go with that assumption, then
> read on.
> > Ok, now I've stripped the simplest possible design
> even
> > more -- no client software! Or rather, no dotGNU
> folks
> > have to write any ANY SOFTWARE WHATSOEVER!
> > (I know, it's like I'm a used car salesman trapped
> inside a
> > programmer's body :-)
> > 
> > I'm still operating on the level of strategy and
> market forces,
> > and when someone pointed out the vendors of "form
> filler"
> > software, that got me started thinking (see
> "Co-opetition"
> > and that ilk for books that have warped my mind).
> I started
> > trying to see various ways those folks fit into
> the picture,
> > and then today I realized that they should be
> cooperators, not
> > competitors. So, here we go:
> > 
> > The Absolute Simplest Design of Maximal Use to
> dotGNU's Goals
> >
> ===================================================
> > 
> > Assumptions:
> > 
> > a) dotGNU needs exponential growth that starts
> Real Soon
> >      to have any hope of catching up with
> Passport.
> > 
> > b) dotGNU will have to define or endorse a data
> schema at
> >      some point so that, for example, your
> software can
> >      ask my software for my "Shipping Address" --
> they both
> >      have to agree on the names of things.
> > 
> > c) Having a dotGNU-branded solution to the
> *current*
> >      single logon needs of end users and web page
> flunkies
> >      up and running on thousands of web sites and
> in use
> >      by many thousands of end users by the end of
> the year
> >      would be *extremely* helpful in selling more
> complex
> >      dotGNU solutions to these same sets of
> players later.
> > 
> > Proposal:
> > 
> > a) Begin immediately defining the first version of
> a schema
> >      for personal data (name, address, credit card
> #, etc.).
> >      This work presumably has to be done in any
> case.
> > 
> > b) Work closely with all the current vendors of
> "form filler"
> >      software in developing this schema (which
> would be a
> >      good idea anyway, because they probably know
> much
> >      more about what kinds of fields web sites
> actually use
> >      than anyone here). Their motivation is to
> support
> >      this standard so their software works better
> and has
> >      some hope of surviving if Passport usage
> continues to
> >      spread. They, not dotGNU, will supply the
> client-side
> >      software -- they've already done 98% of the
> work!
> > 
> > c) In addition to this schema, define a MIME type
> that allows
> >      web sites to specify requests for data fields
> from the
> >      schema. This MIME type will look a whole lot
> like the
> >      schema itself, except it also lets a web page
> flunkie
> >      specify a set of requested fields, and how
> those fields
> >      should be transmitted to their web site.
> > 
> > To elaborate on (c), here's a basic flavor
> example. As a web
> > page flunky, my web site administrator gave me a
> CGI program
> > I am required to use for logons. It is at URL
> "/cgi-bin/logon.asp",
> > and it expects an HTTPS POST containing two
> fields: "MyName"
> > and "SecretPassword". Assume that dotGNU's names
> for
> > these fields have been defined to be "Name" and
> "Password".
> > My current logon web page (the one containing a
> form
> > that will be POSTed to /cgi-bin/logon.asp) is at
> "/logon.htm".
> > 
> > To support the dotGNU single logon standard, I
> create
> > a data file at "/logon.gnu" that contains the
> request for
> > logon information, it might look like this
> (example only --
> > don't hold me to details!):
> > 
> > <dotGNU-Request>
> >      <method>POST</method>
> >     
> <URL>https://www.mysite.com/cgi-bin/logon.asp</URL>
> >      <Name>MyName</Name>
> >      <Password>SecretPassword</Password>
> > </dotGNU-Request>
> > 
> > Given this file, I now modify "/logon.htm" so that
> it
> > contains this somewhere:
> > 
> >   <embed src="/logon.gnu" height="1" width="1" />
> > 
> > I'm done! No coding, no certificates, no
> third-party servers,
> > no installation of software, I probably don't have
> to
> > get permission from anybody in the corporate
> hierarchy,
> > and so on and so forth. My web site now supports
> > automatic logon for any client software that
> supports
> > the dotGNU standard. (I'm actually fudging here,
> > as I haven't worked out whether <embed> is
> 
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/