It's been rumoured that Derek Atkins said:
> I would also warn you that if you split the CGI, you then completely
> lose the benefits of any security, unless you pass the security
> metadata across from one program to the other.
???
A common way of providing 'security' with http/cgi is to
to give the user a crypgraphically strong (e.g. md5) cookie
after you've authenticated them. You use SSL so that no one
can snoop the cookie. After that, the cgi-bin can look up
the cookie (e.g. from an sql database) & choose to accept/deny
the message based on that.
You're gonna have to invent something similar for RPC's, unless you
plan to have the user re-type a password every time a tcp conection oes
down.
> True. Except we can learn by example; looking at other systems that
> have used existing technologies and see how they behave.
!
After years of staring at rpc's and corba & wondering why they've
been failures, the xml-based attempts are a breath of fresh air.
Of course, the xml/soap flks have a whole new set of ways of doing it
wrong. Witness that abomination called 'DTD'. Clearly, whoever
designed DTD's didn't know IDL's from a hole in the ground.
My complaint being that DTD's should have been usable as an IDL,
but they're not. They're *almost* so, but irritatingly missing
crucial info (e.g. typing, distinctions between methods and data,
etc.)
On the other hand, rpc/corba IDL's have failed because they
are too hard to create/parse/work with. e.g. What does 'swig' do?
It 'guesses' a kind of IDL by parsing C headers, and then
generating perl bindings. Do you think swig would be needed
if every C programer bothered to write an IDL?
or another example: g-wrap. Which defines a kind-of IDL, but
in scheme. I once asked rob, 'why didn't you just use the
crba/rpc IDL language instead of rolling our own?' Answer:
corba/rpc IDL's were too hard to deal with.
--linas
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel