Neil Nelson wrote:

> >The database editor that is to be the main part of such a function will

> >also be in the Installer, so it will be coming at about the same time.

> 

> Having a fairly complete ability for Harold to test his Flexhash would be a

> good benchmark.



Added to my priority list.



> And in addition to functions, there are the various items of resource data

> that can be gathered at the same time.  How much disk space has been

> allocated for the ICSA?  How much disk space has been used?  What ICSA jobs are

> currently running on that computer?  What is the remaining available CPU

> resource for that computer?  What kind of computer is it and what is its

> OS ?

> Harold has a number of items that could likely be included here.



You really keep me wondering why you need these, because beside maybe

the OS and CPU use, these are things that the user would like to keep

for himself.



> You may be thinking that each computer would poll all the others and get

> the then available system functions.  In a sense this would be a kind of

> pure P2P where there would be no centralized information as in a system index

> and each computer would need to ask each of the others in turn as to what

> functions were available.  Of course with a central server, then there is no

> difficulty utilizing some centralized system index.  Even in a pure P2P,

> once one of the computers in the P2P group has obtained its own system

> index via a request of all the other computers, any computer that happens

> to connect to that already indexed computer would be able to utilize the

> already assembled index.  And since all computers from which index

> information had been requested could keep a list of requesting computers,

> a new computer would only need to contact at most two computers in

> order to obtain an accumulated index.



A centralized system perhaps seems simpler, but it's nothing more than

another part in the chain. Keeping a personal index of all functions of

each computer may seem a bit space consuming, but to tell the truth, it

isn't! All this information would be stored in disk files which truly

are target-computer specific, which means that unless the user has 3 kB

of disk space left, this shouldn't be and issue and that searching for a

function doesn't really depend on the number of computers in the

cluster.



Constant synchro requests would realy just make more traffic, while not

even ensuring an up-to-date index. This is why you can tell me to code

up a procedure in the Console, that will make the synchro of the

required function, when required. This is not particulary hard, because

when you change the status of a function, that status needs to be

written to memory, then why not to the computers as well. (Which just

reminds me that I have to write a phrase for the removal of a function.

I'll add this to my priority list.



> But these divergent details aside, I think that some kind of broadcast and

> receive feature should be provided.  An issue is that each computer will

> want to control the kinds of communications it receives and sends such

> that a broadcast send and receive is somewhat against having that kind of

> control.  In the tightly controlled encryption sequence, a computer will

> only effectively receive from computers for which it has a uniquely defined

> password method.  In this way, an unknown outsider would not be able to

> easily drop a program on a computer and run it to the detriment of the

> owner of that computer.  And it may be the case that a computer would not

> want to even allow its ICI existence made generally known so that a blanket

> broadcast to that computer by an arbitrary computer could not occur.



Well this is your area. =]



> A central theme here is that the ICI system obtains some advanced

> capabilities by accessing a person's computer in ways that could easliy be seen as

> invasive or as computer hacking.  It seems to me that we will need to be able to deal

> with these issues in an effective manner or we will not have as many

> customers as we may otherwise could.



Between the Console and the target person's computer system, there

always will be an ICI function, which will take care if the security.

Even in the case, when the target computer is supposed to install and

run a program, there will be the "install and run" function, which

should make sure there are no harmfull procedures in that function. Once

we have enough comps in our clusters, we can even suppose we can do

world-wide erradication of harmfull worms, trojans and viruses.



The Console, right now prompts the user for anything that could be

considered as harmfull.



> Yes, I think advanced search methods from AIMetaSearch could be easily

> controlled via the ICI system or could provide input to other ICI

> applications.

> One of the issues that I would like to work out shortly is to have a local

> program such as the ICI Console or ICSA provide HTML input directly to a

> web browser as if it was receiving that via the Internet.  Getting a web

> browser to inferface to a program as against an Internet socket seems to be

> a sticky problem at the moment.



Not at all. Simply SHELL "Start [URL]" will load the html in the default

browser. A problem occurs when there is more than simply the HTML path

and filename to the URL (for example #targets and the like). For such,

there still is the option to use MS's bolted software: Place an IE box

into a window and write the code to make it open the URL.



--



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

