Hello Neil,



Are you ok for debugging now?



Neil Nelson wrote:

> >Due to the fact that the ICSA supports FTP, the ICI web

> >(ici://ici_server/downloads) support is included in this module, it

> >appears however that I have got a minior problem with Windows/Linux

> >compatibilty. Namely "ici://ici_server/downloads" means the path of

> >"/downloads" (linux root!), so the windows version should be

> >"ici://win_Jure/C:\ICI\ICSA" to be appropriately parsed, however this

> >would mean the path of "/C:\ICI\ICSA". I would need the ICSA to eat the

> >leading slash. What is your oppinion of this?

> 

> You would just put `ici_download' as your parameter and then the directory

> path that will be from a top directory on the ici_server that I will

> designate

> in my ici_server icsa.cfg file.  That is, I will take the first part of

> the path

> from the icsa.cfg file on the Linux box, append the path you send, and then

> that complete path will give the file to be downloaded.

> 

> ici_download ICI\ICSA\file_name



I am not familiar with this format. Perhaps I am using an old copy of

the ICSA documentation. My current module uses the "FromName

ici_server", "fteAction Copy" method. How is "ici_download" used? Can I

have a working example of such a command file?



> >About the FTE Call_Directory command... Can my programs use "ToFileLoc"

> >to recieve the directory list?

> 

> Currently it returns to a particular file, but it would seem that it

> would be easy enough to append using ToFileLoc as already being done.  It seems like

> a minor change.



It would appear to be an appropriate feature, for better integration of

the ICSA and my applications (Console and below).



The current "Installer" is made not to require a functioning Console,

only a FileLoc, which I plan it will create on it's own should it be

missing.



> On the Linux box it seems as though there would be a top ici_download

> directory under which the various application directories would be placed.

> I expect we would want the Linux directory structure to be similar to the

> user computer structure to make things simple.



My "Installer" would basicaly need some general information* to begin

with. I guess this information could be placed in a file at a fixed

location and then downloaded and read, but that does not appear

consistent with the current ease at which my programs can ask an ICSA

process for some information (not via the Console, but via my new ICSA

interface module, they can send directly "ToProcess").



[*] = This would be:

 - What the available programs are

 - Their describtions

 - What documentation/extras go with what programs

 - Where exactly all these files are



According to the "pay" theory, we could have users buy the programs

first and then have exactly the ones they brought (just updated copies

of course) available for them on the downloads server, besides recieving

them in the ordinary software package by snail-mail.



> If you are interested in the exact FTP parameter sequence currently used

> in the ICSA, I would just start with the documentation, icsa00.html, and

> make whatever minor changes you think should be done and then we

> can finalize it.



Yes, that's what I did. I attach a copy of the current interface module

for whatever you might need it.



> Or I could add the unzip to the

> ICSA FTP sequence which may be the best.  I would need to have a new

> parameter indicating that the file, when received, should be unzipped. We

> could use

> 

> unzip



If you can find a freeware (pk)unzip program for us to add to the

package, my Installer could easily use it to unpack any ZIPs.



> Also, I am working on the base install.exe and have reduced my direction to

> the last wizard.exe format.  That is, I can use that program directly

> without needing to use the other components I sent you.  However, and I should

> point out that what I send you works on my Win98 box, I need to know if

> that last wizard.exe will run on your box.  And although it is not

> essential, it will be good to know whether or not the last install.exe ran on your box.



Wizard.exe runs fine, atho it does not do anything. Install.exe did not

run on my box, tho.



> I am looking forward to testing Robert's install with you to be sure that

> you know it is working before Robert gets it.  These installation problems

> should decline with our new installation programs, and the ICSA bugs

> should also decline since I do not have plans to make major code changes

> as I have been doing up to this time.  I am adding GUI, but that is more of

> a wrapper than dealing with the core code.



Robert will not be available to debug today, was the last status update.



> Also I got to thinking that your installer could be a rather significant

> part of the system.  That is, we were previously saying how we wanted to be

> able to transfer programs easily to other computers and run them and this

> would be a way to do that.  Also the idea that we are automatically

> updating and installing programs as a routine, possibly daily or as

> conveniently determined, instead of with the idea that user gets around to

> it whenever and likely after a long time, seems to have good potential.



The current "Installer" structure I had in mind was that the GUI program

that I've just sent you creates a kind of instruction set (readable to

the user as well, automaticaly opened in Notepad if user selects

"Provide instructions"), which is then read by another program (ran

automaticaly by "Installer" if the user selects "Install Now

(immediately)"), which does the communication back to ICSA to download

the programs (this way even "Installer" GUI updates are possible). This

program could easily be made usable in real time, by other ICI programs,

even to the point of (you've mentioned a long time ago), downloading

cooperating programs and running them, on remote request. Of course this

would all still be protected by the Console's standard

user-and-function-specific security.



> The primary issue of course is that the user will want to know that what

> we are downloading is appropriate for them.



This is only a question of GUI, I do not see it as much of a problem.



C'ya!



--

Cellphone: 0038640809676 (SMS enabled)



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

reply.

[AC/HFA(AS) -- no suprize]



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

