ShellInterface.Imported @ jos.sf.net

This page is obsolete, but you should read it anyway. Thanks.

Interface definition "Shell"

Purpose: baseline interaction of UI with other subsystems

Features:

send message to another process/thread
receive message from another process/thread
should make use of a system daemon for all this..

Maintainer: BenKnowles

Status: design first prototype

Source code: pseudo code below

Current users: none of those either

Current implementors: none as of yet

Possible implementors: everything

Version history:

16 July 98: I got tired of waiting for someone else to do it
29 July 98: Still taking Input, Inquiring into existence of messsaging in JOS
25 Dec 99: Added more explanation, pseudocode (here)

Discourse: My last edit to ShellGroup listed these desired behaviours as the minimal needed:

Execute/init classfile
Send message to (running) process/thread
Receive message from (running) process/thread

In fact, the first one (and the verify bit commented out above) can be eliminated if the messaging is set up right. The shell can message someone to run whatever classfile it wants to. So, the spec currently reflects:

Send message to (other) (running) process/thread
Receive message from (other) (running) process/thread

Do join in the fun. This discussion can always move to another page.

Note: I hack lousy code. However, no work can procede on UI hacking until this minor thing is taken care of (my understanding anyway), and I am tired of waiting for someone else to do it, I'm going to hack it. I will be taking submissions for desired behaviours and such until the end of Summer Term (early August) and then I will hack something up and put it here, just so we can get on with this. Feel free to beat me to it. --BenKnowles

Doesn't it still need to be able to start a process? If not, at least one other process must be available which can start other processes before the shell can do anything. -- AveryRegier 30 July 1998

If I understand your question correctly, then I don't think it needs to be able to internally start a process. What I'm thinking would happen is the bios or whatever bootstraps the bootloader which loads the picokernel which starts the J(V)M , and then init()s some JOS system stuff. Apparently there would have to be a messaging daemon in amongst this 'stuff'. I don't think this is at any lower level than that. Kernel level messaging seems like a bad idea, and we shouldn't need to tweal the VM for this (do we?), so it seems like it belongs in the last category.

This further begs the question: Has anybody done any preliminary work on a JOSMessage subsystem, or am I just lucky? I know a good bit of work has been done in the design of sme of the other things that fit in this part of the system, but has anyone tried to figure out how it integrates with the low-level stuff? Or at least come up with a name for it.. Maybe this plays into the JOS / JOSBox idea ... --BenKnowles

25 Dec 99

Among other things, I have been fiddling around with BeOS lately (having finally gotten a copy of the x86 port). Included in R4.5.2 are quite a lot of sample code and hacker docs, particularly the Be Book (what goes over their APIs)... As I had suspected, their messaging setup is ungoetlich nice. We should be implementing this! The interface (this page) needn't be more than (excuse syntax errors):

public class Shell implements ShellInterface
{
	  sys.register_me_as_messaging_capable();
	  protected boolean receive_message(JMessage)
	  {
			 return(true);	 
	  }

	  protected boolean send_message(JMessage)
	  {
			 return(true);
	  }
}

and maybe should be renamed s/Shell/Message ?

Implementors would overload send and receive as befits their needs. In BeOS, handlers and loops are provided to dispatch messages.. I strongly encourage looking over the online Be Book section on application messaging : 20Application20Kit/topicMessaging.html">http://www-classic.be.com/documentation/bebook/The20Application20Kit/topicMessaging.html

- BenKnowles

Since writing this page, I've studied up a bit more on Java (2). This looks like a job for RMI, but I'm not sure about it. I'm considering starting a adric:MessagingArch or something to hash out the possibilities.

- adric, 15 Aug 2K

Content of these pages are owned and copyrighted by the poster.
Hosted by:

Purpose:	baseline interaction of UI with other subsystems
Features:	send message to another process/thread receive message from another process/thread should make use of a system daemon for all this..
Maintainer:	BenKnowles
Status:	design first prototype
Source code:	pseudo code below
Current users:	none of those either
Current implementors:	none as of yet
Possible implementors:	everything
Version history:	16 July 98: I got tired of waiting for someone else to do it 29 July 98: Still taking Input, Inquiring into existence of messsaging in JOS 25 Dec 99: Added more explanation, pseudocode (here)