Re: security and multi-user

[Tom Tromey <tromey creche cygnus com>]

Shawn> This, initially, was what I thought would be cool about CORBA -
Shawn> but the more I look and read, the more useless CORBA seems.

Hah!

I don't think CORBA is useless.  But I do think that the OMG has put a
lot of complexity in the wrong places.

One thing I like about CORBA is that to the programmer (us users --
not the people writing ORBs) it presents APIs, and not protocols.  I
think the long history of broken protocol implementations shows that
this is probably a good idea.  (And, anyway, I hate writing protocol
handling code.)


Shawn> Even if it is local, at the minimum I need to have more than
Shawn> one user per machine.  Imagine: "Sorry, someone is using an
Shawn> addressbook already, find a different machine..."

Shawn> So how do I go about this goal? 

This part you can do.

For Gnome I think we are going to run a master instance of the CORBA
Name Service (that is, one instance per "session").  This is one way
that a Gnome program can find the objects it wishes to talk to.

You could just make a new address book object and register it with the
Gnome name service.  Then address book clients would use the name
service to find the address book object.


In fact, I'd argue that this is the way to go even if you have shared,
remote address books.  In this case the "local" (to Gnome) object is
just a proxy that talks to the remote address book (or several,
presenting some merge of the contents).  The reason to do it this way
is that it puts the complexity in a single place -- the proxy --
instead of in every client.  To a client, it just looks like there is
a single address book.

You can even write proxies that talk CORBA on one end, and something
else on the other end.  You could use this to integrate with
preexisting address book packages and servers.

Incidentally, the CORBA Name Service takes a somewhat similar approach
(there are differences, though).  It is possible to have different
domains in the Name Service servcied by different NS objects.  To the
client, the interface is seamless.

One last thing: if you know that the user only wants to use a
particular remote address book object, then you could just register
that object with his local name service.  The remote part is no
problem.


[ stuff about crypt ]

Shawn> Now, why *don't* I want to waste my time doing this?  (Please,
Shawn> tell me now before I start...)

CORBA does have a Security specification.  I haven't read it; I
understand it is quite long.  Anyway, ideally the problem would be
solved down at the MICO level -- somebody would write an
implementation of the Security service for MICO, and we would just
start using it.

That way the ugliness of adding crypt() calls to all our code would be
replaced with some ugly standardized calls instead.

Perhaps looking in on the MICO list/web page to see if this is in
progress would be a good first step.

I imagine it would best be implemented by someone outside the US.
Sigh.


Hope this helps,
Tom