Shibboleth Developers

[Derek Atkins <>]

Scott Cantor 
<>
 writes:

> I wonder, though, why do you think that all of the other "connectors"
> people write these days for these web plugin->service interfaces
> (Tomcat's fifteen different connectors, scripting engine connectors like
> Cold Fusion's, etc.) never use RPC?

You'd be surprised how much actually _does_ use RPC; if you run
Solaris, it's used for a lot of your daily work.  NFS uses RPC, as
does NIS, and even gssd (for krb5-nfs).  My personal feeling is that
most programmers today ignore RPC _because_ it's so ubiquitous.  It's
not an "interesting" technology to use.  However, you can look at all
the other technologies that have tried to reproduce RPC's simplicity
(the most recent examples being CORBA and SOAP).

> It's a serious question, I'm not really arguing with you. I get the
> feeling that most developers really detest RPC for whatever reason
> (certainly one reason among many DCE is dead), even in places like this
> where it's really helpful.

I think DCE died for other reasons -- I don't think it died because it
used or provided an RPC.  The problem with DCE is that the RPC was not
easily separable from the rest of the system.  It wasn't a piecemeal
thing, you either ran ALL of DCE, or you ran none of it.  You couldn't
run the RPC without the Security Service.  You couldn't run the
Security Service without the Naming Service.  You couldn't run the
Naming Service without the Time Service.  You couldn't run the File
Service without all the above.  So, saying RPC is bad because DCE
failed is actually missing the point (or at least learning the wrong
lesson).

> For one thing, this should make it pretty straightforward to embed the
> SHAR and the caching engine inside the web server, by localizing those
> RPC calls. The practical fact is that everything most people use today
> likes threads well enough (including Apache 2, mercifully), and on
> Windows, you don't find web servers running multi-process, so there's a
> lot of mgmt and performance overhead to splitting it out that can be
> eliminated. I like having the option to split it alot, I just don't like
> it mandatory.

I was going for simple, straightforward, and _easy to implement_.  You
are right in that modeling the system as an IPC/RPC allows you to glom
is all together if you wish.  However, getting that "right" in a cross
platform system is more time consuming than just running a separate
process.

Note that my model was like a SQL Server...  SQL Server runs a
separate process that isn't tied to the web server.  I'm viewing the
SHAR just like that.  Note that the SHIRE and RM, which really are Web
Server functions _are_ tied into the Web Server -- the functionality
is in the Core Library, which is not accessed by the RPCs.  So, you
are no worst off than if you were trying to store all your state in an
RDMBS.

> >      For flexibily and extensibility, I propose to implement the
> >      policy configuration as a scheme plugin.  This allows a simple
> >      text-based configuration but also extremely powerful paradigm.
> 
> By scheme, do you mean scheme literally? As in the LISP-like language?
> Or is that meant to be schema, as in XML or something else?

Yes, I mean scheme literally.  Yes, as in the LISP-like language.  I
envision something like this (for a simplistic example):

'((http://www.mydomain.edu/my/application/ (member:mit-staff 
member:cmu-staff))
  (http://www.mydomain.edu/your/app/ (member:mit-student member:cmu-student))
  (http://www.mydomain.edu/ (any)))

> -- Scott

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       

                        PGP key available

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--