Regier Avery J wrote:
> Not necessarily. I envision the possibility of there being many toolkits
> available just as there are many X window manager available. Each shell
> (which extends off of JADE) may implement the Toolkit differently. I
> personally think it is a mistake to embed the Toolkit into JADE. I had
> envisioned JADE as being flexible enough to be the base both TUI's and
> GUI's. Most TUI's won't have a Toolkit at all. There will be some GUI's
> which don't want to use Swing as their peers. We need to give the shell
> writers the flexibility to do whatever they please.
Your absolutley right, what ever I was thinking when I said that is...
well.
What we should do is have a JOSToolkit that provides all the base
functionality, like getSystemClipboard() isnt going to change, then have
various subclasses like SwingToolkit to provide the default
implementations. I think we could use the Toolkit in a CLI anyway for
stuff like beep() and that just throw something akin to a
GraphicsNotSupportedException.
Now that I think about it we could define the default JADE toolkit to
get a HashMap from the registry and create the peers from that... (the
default being the Swing ones)
> I'm thinking that the Registry is the prime opportunity for hackers to get
> around the security model we implement. We require a Registry for
> configurability, but it will also have to contain settings that directly
> specify security. For instance, if we set in the Registry as a default that
> applets may only take up to 30% of the CPU and 1/4 of the System's RAM, and
> we didn't secure the Registry such that those settings cannot be changed by
> hostile applets, we have failed. If the system administrator sets the
> settings such that a user 'guest' may only access certain files, and the
> guest is able to get in and hack the registry to give himself more
> permissions, then we have failed. One way to ensure that the registry is
> only changed by those with permissions to change it, is to encrypt it. Not
> just that, but make sure the decryption routines are secure as well.
or we could follow KOH (the DOS virus people intentinally let on their
systems to encrypt all their disks) with extra security of course, and
just for the hell of it encrypt the security section of the registry and
require superuser access just to be asked for the pass phrase (you'd
need a small nuclear weapon to get throught that ;)
> Glad you asked! I'm not really sure! Right now the system I'm playing with
> is that it is all controlled via the shell. For instance any process can
> also be a parent process. It can spawn other processes. If the parent
> process decides that it is willing to share {x} static data with the child,
> it may. If the parent spawns two processes, and gives both permissions to
> its statics, then WALAH! IPC. Shells are the parent process for most every
> application in the system. The shell would check the registry to determine
> what static class data, if any should be shared with that process. The data
> may not come from the registry, but also could come from user commands, be
> they GUI in nature or text commands. If a GUI shell spawns a text command
> shell, then it is possible that an app launched from the GUI and an app
> launched from the command shell can do IPC. This is a simple explanation of
> a tough problem, but from JADE's point of view I'm hoping that it will be
> just that simple. It is not so simple from the kernel/JVM point of view.
> This complicates the memory and process management tasks a lot. Figuring
> all of this out is really what the org.jos.core.* project is all about.
> This is also why I want JADE to be more generic. Its job is to make all of
> this process stuff easy as pie for shells. All shells should really have to
> worry about is human interaction. JADE takes care of interacting with the
> system, as this is what must be consistent across all shells, otherwise our
> users would go batty trying to keep it all straight.
exatcly!
system <> JADE <> UI
couldnt have said it better myself
the system is considered with doing... um, system stuff not looking
pretty and making a noise telling you you cant click there
> The definition of a process must be consistent accross all shells. You
> start and stop and kill processes with the same API into the jvm+kernel. A
> process whether started from a TUI or GUI is defined the same way for
> security and configuration in the registry. JADE should make it simple to
> pull all of that information together so that when a user clicks on an icon
> for Netscape, the shell just says to JADE, "JADE.getProgram("Netscape",
> "Avery").createProcess();" and it all just works.
I imagine this getProgram method to be incredibly complex and Im sure as
hell not writing it, but Id like it.
before Gilbert brings it up though it should except a URI as the program
Cheers,
DigiGod
_________________________
[EMAIL PROTECTED]
AIM:DigiGod 86
_________________________
Quote of the Moment:
Thus spake the master Ninjei:
"To the intelligent man, one word, to the fleet horse
one whip, to the well-written program, a single
command"
_________________________
Prank of the Moment:
Using the conferencing feature of your office phone, dial
one Induhvidual, then while it's ringing dial another and
conference them together. Put your own phone on mute
and listen to see how long they'll make small talk before
figuring out that neither one placed the call.
O-
_______________________________________________
UI maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/ui
