[283] in Athena_Backup_System
Re: crippled mode server issue
daemon@ATHENA.MIT.EDU (Bill Cattey)
Tue Jul 2 13:21:44 1996
Date: Tue, 2 Jul 1996 13:21:21 -0400 (EDT)
From: Bill Cattey <wdc@MIT.EDU>
To: athena-backup@MIT.EDU, delgado@MIT.EDU
In-Reply-To: <9606281259.AA21482@ops-5.MIT.EDU>
Excerpts from mail: 28-Jun-96 crippled mode server issue delgado@MIT.EDU (902)
> "svc_run" is an rpc library call which under normal
> circumstances never returns. Its function is to
> listen for incoming network requests and execute
> the requested interface call.
> This model does not naturally lend itself to being interactive. I think
> we need to specify in more detail how this is going to be implemented.
Hmmmmmm.
Sounds like an oops.
Suggestion: Let's NOT modify the Crippled Mode spec just yet.
Let's think about the right way to do this and do it in the simplest
possible way that enables the functionality we require.
At the moment I am not sure what to suggest as an implementation.
I don't think we can just use the normal mode User Interface module,
because wholly different information gets exchanged. (IE the Crippled
Mode Master prompts for a lot of information that the normal UI assumes
just gets fetched from the DB.)
We may decide to split off the Crippled Mode UI as a separate process.
Anybody got a guess how much additional coding THIS would be?
We COULD get really nasty and have a simple front end process that does
a Blocking RPC to the Crippled Mode Master to exchange character
strings. IE The crippled mode master would have additional RPC's
registered to receive command strings and argument strings. It would
export an RPC to display prompts.
I suspect such an approach is UGLY!
Am I learning from this that ONC RPC is "not a real rpc" because there
is no way to register an internal routine to operate periodically from
inside the svc_run loop?
-wdc
