client-server

[linas@linas.org]

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