Neil Nelson wrote:

> Yes, I did not carefully consider that there were these other communication

> protocols.  I am at the moment following your suggestion that the command

> sequence for the ICSA be a set of parameter names followed by parameter

> values, and this seems to be a rather direct way to approach the

> problem.  It reminds me of the very minimal mathematical and program function syntax,

> which theoretically is all that should be required. Applying a more compre-

> hensive syntax structure clearly adds information according to the syntax,

> but then we lose a flexibility in adapting the syntax.  But this is only

> a minor observation.  I expect we will go with what we have at the moment.



The data storage system is basicaly indentical to the MicroSoft INI

format (which is indentical to the Registry format, but unfourtunately

the registry is nearly useless for the OS to OS diffirences) and still

reduced. The command passing format, however does not have a direct

indentical with MS; it is made of entries like a list.



I used such formats, because they can be easily read and edited by the

user using a simple text editor.



> Harold mentioned yesterday that he has some very significant and thorough

> input for the overall look and feel for the ICI Console, and I have

> requested that he provide the specifications as soon as possible.  Since his

> modifications are expected to be significant it will not be prudent to make many changes

> until we get his input that I expect will be ready by Sunday.  I would

> work on areas that are somewhat obvious including the install program and the

> Society function, which seems to me to be a kind of newgroup/listserver for the ICI.

> And of course you will want to provide your ideas for user-friendly changes

> so that can be merged with Harold's specifications.



I think any interface modifications will not be hard to fit. There are

only problems if new options should be introduced. But well I can't say

now, I would require to see what I am expected to modify in order to

give appropriate comments.



> >It is just so that my "Do.txt" file (contains things that require to be

> >done) is getting bigger and bigger.

> 

> Yes, I see that you are well organized.  Determining clearly what all our

> coordinated priorities are seems to be the first priority.  Over the

> short run we need to get a unified direction, or we need to identify a less

> unified coordination that makes clear sense.



What I was trying to say is that the place where I was programing has

undergone some minor fixes, which means that I couldn't do any

programming for the last few days. Everything is supposed to be

finnished tomorow, when I can clean up, do some immediate tasks (for

school) and resume programming.



> I agree that we need to have a product that will be different from other

> products and where that difference is something customers will be willing to pay for.

> But we can still attempt to sell what is being sold.  People have been

> selling shoes and bread for a long time.  But in any case we need to identify

> clearly what we want to initially sell and then do that. And again your

> input--which may include a significant product difference, and I think we may have some

> significant product differences--should be provided so that we can coordinate

> that with Harold's product plan.



Sure. I'll be ready to do any modifications as long as the functionality

remains the same. Tho I understand the nature of the market: People

almost never buy radical ideas.



> I think your graphics abilities are very good and am looking forward to

> having a website either designed by you for selling the product or that

> displays much of your graphics work.



I could put it on my priority list, but actualy I do need some

information for it. Namely the supposed content of the page.



> Yes, I think the ICI central server functions will include many of your

> current functionality plus many others requested by Harold.  Harold's viewpoint

> seems to stress a centralized control of the ICI that then requires a

> fair amount of software centrally located to enable that control.  The initial

> product area we seem to be looking at typically has no centralized control in that users

> want to buy the product and use it on their own.  This is the standard

> software product method.  I am thinking that we will likely need to emulate that

> usual method initially and add in some minor centralized functionality to enhance

> the product such as the centrallized dynamic IP manager.  Time sync for

> increasing security is another but more distant centralized function that is

> only good when that area comes up to speed.



With the abbility to function without a centralized point in place,

there is an immediate abbility to function WITH a centralized point. The

ICI system can handle it all. The idea however needs to be that the Head

Node is a bit diffirent to the normal ones in order to be able to

enstablish the expected server-client relationship. The diffirence I

have in mind is the cluster managment; the server requires to make sure

that the client does not have to handle information about all the other

clients.



--



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

