Re: [WIN] The installer (iteration 3)
Okay, Round #3 ... 
Kat wrote:
> Travis, i suggest it contain all the internetworking code (such as http
and
> telnet and ftp and etc get and put, when i find one that works 100% 100%
> 100%), and all the string handling includes (like tokens and string.e and
etc).
> And a easy-to-use gui for input and screen display, and diskfile (like
"object
> data = glom(TheWholeDiskFile)" ) and physical port i/o, for the OS of
choice.
> That should about cover it. 
)
Hon, you done it to me again. I can't make heads or tails of what you just
said. Remember, I know **nothing** about internet programming, and very
little about the Internet in general. Please rephrase the above as though
you are speaking to Forrest Gump. (And no, the Internet is not like a box
of chocolates.)
Mr. Ryan wrote:
>Do a search on "install" in the archive.
Did that. I found two programs of interest. I downloaded EuSetup, and
attempted to get Mr. King's app; however, the archive link was to the
spectrum software page, and when I tried to do a search for it, I got an
error stating that the "page had errors" and it could not be displayed.
EuSetup, I'm sure, is a fine install program, but it is DOS. In that
respect, I feel that I would be doing little more than duplicating Mr.
Craig's installer. I'm wanting this to be a Windows venture. Also, the
installer will need to be tailored somewhat specifically to installing
Euphoria, since it'll need to adjust the autoexec.bat file, as the DOS
installer does.
Mr. Bensler wrote:
> I don't think your quite understanding my concept here..
More than likely not ...
> It would need to be a 2 part installation process
>
> The first part.. the component selector, would not actually be a part of
> the installation, but rather, just prompt for the components the user
> wishes to download and install. It would write that info to an init file
> that would also be downloaded.
Oh! Maybe the light just kicked on. Okay, what you're saying is that the
user would go through a process in which they select what they want. Once
they've selected this, then an install package is built on the fly, and then
sent with the installer, right?
> I'm not too familiar with how web based programming works, but I do know
> that it's feasable.
More than likely. The "packager" itself is for use here locally on my
machine, so that I can build the package to send with the installer. It was
not meant for the end-user's consumption, other than perhaps as a demo so
that a newbie can see how I did it. So ... this might work if I knew enough
about Internet programming to write an app to do this based on information
the downloader sends back. Using the current packager, it would be a matter
of ...
1. Getting options from the downloader.
2. Having the packager run at that point and assemble the package.
3. Send off the package and installer in one zip file.
Two problems here that I see is that I have no idea how to get a Euphoria
program to run on the Internet, which is further complicated by the fact
that this a Windows package would be constructed and downloaded from ArNet's
server, which is Unix based.
Secondly, the original plan I had was to build the set up package, then
either have Mr. Craig put it in the archives, or otherwise find a suitable
location for it on the RDS website.
> There would have to be some sort of CGI app that would allow the users
> to select the components they want. And the directory they want them
> downloaded to.
> Once they've made their choices, the app would send out the
> corresponding zips, for each of the components, and create a custom init
> file for the installer to work from.
Ah, here's possibly another difference in the approach. You are talking
about sending out a bunch of files, and firing them off one at a time. In
my strategy's case, I have two files: the installer code itself (bound),
and the data file, which holds the necessary code for all the options, and
the image resources, etc., which the installer needs. (The file
euphoria.dat is nothing more than a compressed EDS file.) Way I see it, the
less files we have to deal with, the less of a chance of the end-user
accidentally misplacing one somewhere betwixt hither and thither.
> In this way, the user can download the components, and then store them
> to disk if they wish to install on a different system or for
> reinstallation.
>
> When the user is ready to install, that's when they would run the actual
> installer which would install EU based on the settings stored in the
> init file created by the online app..
>
> As for component compatability, that would be determined in the cfg file
> for the online app.. which would store the locations of the various
> component options.. That's entirely up to the person who is updating
> that file. The cfg file would ONLY contain compatible components. It
> doesn't have to support the latest version of the components..
>
> This would be the easiest way to keep the installer up to date..
> You would never have to modify the installer or the online app, only a
> single cfg file.
And now, consider a person like Kat. All scripts are forbidden. No VBS.
No JScript. No ActiveX. A byte of data can't sneeze unless it has a
Kleenex to wipe itself off with. Now suppose she goes to download this bad
boy ... then what happens?
We'll get this figured out ...
-- Travis --
|
Not Categorized, Please Help
|
|
