Neil Nelson wrote:

> Thank you again for keeping me on track at 6:15am.  Saturday I was able

> to clean all the compile and link errors out of the 7 programs making up

> the first version.  I also began looking at the detail TEA Total code for

> extraction of the TEA routine for use in the encryption block.  In the

> morning on Sunday I extracted and compiled the DES code from PuTTY

> for use as another ICSA symmetric encryption method. And then Harold

> sent his Flexhash PowerBasic program to me, which is a prime component

> of his logon procedure, and I converted it to C++ in the afternoon, and

> then we discussed how to manage the ICI system-time later on.



Excelent. I suppose the existant NTP time synchronization protocol can

be used (because it's far more appropriate for this than anything else)

and an add-on program is asked for the synchronization service.



> Today I will be working on debugging the ICSA so that it will send and

> receive messages from already existing, simple TCP client and server

> programs on the Linux box.  And then I need to port the code to Linux

> and have two versions communicating.



Sounds exactly like the way the Console was devoloped. =]



> *** Notes on ICI cosmetics.

> 

> After just looking at version 261 again, I can see that you have organized

> things quite well into the basic three areas of: Cluster, Function Server,

> and Communication. Perhaps those somewhat separate function areas

> could be emphasized more so that the user quickly sees that he should

> focus in one area at a time for certain purposes.  The number of variables

> considered and hence the degree of potential confusion is reduced by that

> focussing. Perhaps a more striking border around those three areas would

> assist the focussing. The names of the three areas may need to be consi-

> dered for an intuitive understanding of the purposes of that area and made

> more prominent so that the user can quickly recognize which area they

> need to be in.



The Console has one big window with multiple entry areas grouped in the

3 frames. Just the code bulk that tells the app where to locate the

components (entry areas, labels, buttons, etc) is over 21 KB and

represents at least a fair third of the total code. The entire Console

window is too big to fit on a 480x640 screen. If I wanted to make it

easier to handle now, I would split it to 3 windows, but this means that

the windows would have to be made spanable to fit the screen as the user

would like and consequentaly tripple the amount of the code bulk for

component location, which would all be solid typing for me. A reason

good enough for me to keep things as they are now. =]



Anyway, as I slowly automate aspects that were previously supposed to be

controled by the user, there are less and less input boxes on the

window. The current version 263 that I will send in a seperate post, has

one such box less... ;] but expect I will remove more later. It's mostly

because some paths need to be fixed for the diffirent add-on apps to

know where to leave their orders and requests.



> Cluster is where the connection activity takes place and the user needs to

> intuitively understand that this is the first place he needs to go.  It

> seems as though there should be an ability to select the people/computers they

> want to connect to from a list.  That is, in some manner there should

> likely be a name list from which the user can select names either one at

> a time for single communication or perhaps several by, say, holding

> down the ctrl key.  The window showing the icons only has additional

> icons currently when another computer is connected.



The information on the Cluster screen will eventualy all be stored in

files that can be created on install. Currently I'm sure it's hard to

understand as you have a self-extracting RAR package in place of the

installer, but later there will probably be an installer that will

interact with the user and put up an optional innitial configuration,

maybe even with a program for managing who is in the cluster installed.



Tho I probably will add 'colour managment' to the Console as an option

that can be turned on or off and would help the user understand what

needs to be done next.



> And so I am Joe-user who barely knows how to surf the net and wants

> to use the ICI to chat and I have never used it before.  I click on the ICI

> desktop icon and the ICI screen comes up.  I might be looking for

> something that says `chat' or says `connect to remote computer'.  I am

> doing a kind of search on the screen for the few things that Joe-user

> knows to figure out how to do chat.  Maybe its just a help-like menu

> that takes me through the steps; perhaps a search through a help.



As the Joe-user that who barely knows how to surf the net, you will

chech a box on install and the Console will start up and connect

minimized togather with windows; then when you want to chat, you will

run the chat add-on prog and you're good to go! =]



I will send you the current chat-forum program that works via the

Console and you will see how easy it is to work with it. It is a perfect

example of a add-on prog for ICI with an independend UI.



> And then, as Joe-user, I want to log in to my home computer from work

> and transfer some files to assist my work.  I click the ICI icon and then

> look for `file transfer', `remote directories', `remote file manager'. I

> may then want to start a program on my work computer from home, and

> might be looking for `remote command line' or `remote run'.  It is a

> kind of web-search in a visual space; we have vague words or symbols

> from prior experiences used as keys to match up with the visual clues.



In my idea of the file manager add-on, it will be very simple: You would

only have to type or click in the details you felt were important

(filename and/or extension and/or first few lines and/or computer name,

etc) and send the request. It would be then crossposted to multiple

computers, their Consoles would make a deal on what computer should

reply to the request with the file of course. Everything an app would

need to provide this service would be the functions to find the file on

the local disk, upload it to the remote computer (ICSA?) and of course

the user interface (which dosen't represent a very hard coding effort at

all).



Data backup also comes as a good idea here. I imagined that the upload

request would be crossposted to multiple computers, which would... yes

same procedure; the end result should be data uploaded to multiple

computers, but not all of course. The download request would then be the

same as the one mentioned above. 



> But things are looking good, and I need to get back to the code.



A hint or two about the esthetics of what we make: We should make the UI

things look cool because, with the interapp and intercomp communication,

we have the technology to make any kind of add-on app we wish in an

afternoon (the chat-forum thing was... ;) with a fair chance to

redecorate it in the next day. If I look at this Netscape browser for

example, I don't get the slightest impresion of what technology this is.

I will definately give my add-on apps a hi-tech look; never compromising

usability with esthetics, tho.



--



Don't feel bad about asking/telling me anything, I will always gladly

reply.



Digging for info? Try AI Meta Search:

Http://WWW.AIMetaSearch.Com



MesonAI -- If nobody else wants to do it, why shouldn't we?(TM)

Http://WWW.MesonAI.Com

