[Threedsia-dev] (no subject)

[Eric B. <eb...@us...>]

I am including a slightly editted version of a log from the irc
channel...you guys might check it out...but I am going to more or less
restate some of my ideas in this e-mail

What I am proposing is to re-engineer 3Dsia just a little bit to be more of
a visual shell.

The idea will be still have a 3Dsia server daemon and a 3Dsia client/shell.

The 3Dsia server daemon will be similar in idea to an irc server.  It will
handle tracking of remote users (using the 3dsia client) as well as their
current location.  Their current location, rather than being completely
databased, would be based on where they user is from their visual shell
(what their PWD currently is).

I think that the idea of the PWD needs to be expanded a little bit to
include a host name.  This way, if the user is interacting with an external
system, then their location would be ($PHost)/$PWD with PHOST being the
remote host and PWD be the default shell location.

The idea of using some of the existing information may make things just a
little bit easier to accomplish.

The client would display the current directory.  The user could then click
on a file to start up the application (if it has executable permissions) or
start the appropriate helper application (which can be determined from the
mime-type and/or the magic number of the file)  The user could access some
of the built in shell commands (like connect to remote server - which would
require authentication and/or remote access enabled) by doing a certain
action to bring up a list of commands and/or icons linekd to those commands.
The client would read the current processes that are active on the system as
well as the other users, however, this information will really be done by
the server with the client only querying the server (to avoid 10 clients
doing a ps/who every 5 seconds or so)

The servers would interact with each other over the corresponding port (once
again taking after an irc network) which would synchronize who is own and
where they are (their location = $PHOST/$PWD)

The benefits of this is that we don't have to reinvent everything, and we
can take advantage of a lot of the prexisting information already available
(like the mime-type definitions, the magic number definitions, the who
command and/or rwho (if active), the PWD environment variables, the rsh
commands, etc.

There would be only one instance of the client allowed, but there could be
multiple sessions (allowing for a user to multitask by viewing other
directories..this would be like starting multiple shells/xterms)

So once again:

Server:
 - poll local active users
   * current host
   * current directory
 - poll active processes
   * who is running it (link to a user perhaps)
   * what files it is interacting with
 - poll client for information
 - identify other 3Dsia servers
   (maybe we can have an IRC bot somewhere to poll and
    respond with a list of registerd servers)
 - synchronize server user info

Client:
 - register with local Server
 - wait for active user updates from server
 - wait for local user commands
   * built in commands
     + connect to remove
     + execute command - if they have permissions (visualized as if they
have the key to open it)
     + message user (talk/chat with bubble appearing above them)

   * files with executable permissions
     - which will log what files are being acted up (read/written)
 - visualize nodes based on mimetype/magic number/helperapps/plugins
   (files, directories, remote connections,etc)
 - execute command
 - display output of command

For an example:

If we have two machines A and B and we have two users John (on host A) and
Bill (on host B)

Host A boots and starts 3Dsia Server
Host B boots and starts 3Dsia Server

John starts the 3Dsia Client on Host A at $HOST/$HOME (which would be
HostA:/home/john)
Bill starts the 3Dsia Client on Host B at $HOST/$HOME (which would be
HostB:/home/bill)

John executes the built in shell command for connecting to Host B

John is resides on Host A but his current working position is on Host B.
Bill would now be HostB:/ (default location - like when you connect with
telnet or rsh)

Since his current Host would be on Host B, he would get information from
Host B and would see that Bill is also on (working at his current position)
John could use a built in messaging shell function to communicate from long
distance or change to HostB:/home/bill (if he has permissions; if he doesn't
then he could only identify and communicate remotely (like on IRC - if the
user is in a private channel you can still send to him but not so that
everyone can see)

Well..this is more or less my babblings for a bit...Tell me what you think

Eric