I've always seen the relative complexity (to joe-user) of installing applications on the empeg as a check on more widespread application usage. Why shouldn't anyone capable of installing and using JEmplode and hijack able to install tetris or pacman or GPSApp?

The largest difficulty in the past has been the complexity of configuring the start up scripts to get your applications to launch properly when the empeg boots. The preinit script was a great step forward (thanks bitt), but the installation was still fairly complex. Thankfully, Mark has greatly simplified this process with the addition of the ;@EXEC and ;@EXEC_ONCE config file lines to hijack.

Now as Tony said earlier, all that required to install a program is to "just copy the files anywhere to /drive0 and put the config.ini line in place and you're done."

Perhaps this entire thing isn't necessary, as it been recently pointed out that it is now really quite easy to install third-party applications using just an ftp tool, simple command line operations in linux like CHMOD, and some utility to modify the config.ini. But here's an interesting idea, and maybe it's just not worth the time over simply adding some entries to the FAQ over how to do an installation and explaining what each thing does.

Granted, it's not terribly hard. But why not automate even that, so that all that's required to install or upgrade a program is to download a standardized, pre-packaged installation file that JEmplode (or a simple standalone utility) knows how to put on the empeg? Uninstallation could then be as simple as scrolling through a list of installed software and clicking uninstall on the appropriate items.

Technically, such software is not very difficult to write, yet reduces the complexity of installation to someone who is not familiar with working with the internals of the empeg, and streamlines the installation process for those of us who are. I think this functionality would be great to have in JEmplode and hopefully would encourage more people to use third party software on their empegs.

To that end, I've toyed around with an idea that Mike Schrag mentioned almost a year ago. That is have JEmplode or some other such piece of software manage the third party software installation on an empeg. This way, once someone has JEmplode and Hijack working (both of which are well documented procedures), he or she need only to browse to the install file in JEmplode and it does the rest. JEmplode then automated the install asking the user a series of questions based upon the state of the empeg and the standardized manifest file listed in package. JEmplode also keeps track of all changes to the empeg thorough installs and upgrades, so that a well-behaved program can be easily be completely uninstalled through JEmplode.

The first step in creating such a system is creating a package format that and application programmer can set up the things JEmplode needs to know about installing, upgrading, and uninstalling the program. The package format would likely be a zip file containing the installation files and a manifest described below. (By using a zip file format, we reduce the bloat required in JEmplode as Java already handles the zip format, and zip compression is easily available on all platforms.)

I took the previous manifest format and greatly extended it to include what "seems like" all the necessary information JEmplode would need to manage the installed applications on the empeg. I tried pasting it in here, but the BBS butchers the readability. (Not that it was that high ) An example format of a manifest file to be included in an application package is now attached at the left.

So would this tool be worth implementing, or just a waste of time?

John

I think this is definately worth the time to implement. With the many applications available for the empeg, and more possibly on the way, a standard way of installing them would benefit many people including myself. I am technically capable of installing all the applications that have been developed (like many others on this board) but I find that the time needed to install sometimes just isn't worth it. I know that other empeg owners whose expertise may be in areas other than computer technology would feel the same.

... that's exactly why i haven't installed empacman, emptris, or most of the other third party apps... digging up the info on how to do it just wasn't worth the 5 minute wow factor after it was done. If there was a package manager i'd be all about it though.

I mentioned in another thread that I have another project that is consuming my time for a couple of weeks, so I wouldn't be able to get to this for a while, but I could work on it afterwards... I definitely sympathize with loren that I don't install 3rd party apps either because it's just kind of a pain, so this would be kind of nice.

This is definitely a killer idea. Can jEmplode edit config.ini by itself, or does it need help from something running on the empeg side? I haven't looked at jEmplode in a while.

I'll be happy to switch my apps over to this when it's working.

... that's exactly why i haven't installed empacman, emptris, or most of the other third party apps... digging up the info on how to do it just wasn't worth the 5 minute wow factor after it was done.

Ditto. The wow-factor apps have to be super easy to get wide-spread usage. The things I have actually bothered to install were things like web interface and empVNC that are more utilitarian.

On a side note, that may be the "killer feature" that would get me to switch to jEmplode permanently.

jEmplode can edit config.ini .. it's exposed as a special FID on the Empeg that i can download/upload just like an MP3.

I love the idea!

I'm getting ready to start working on my TTS system some more and the part that needs the most help is the install script. Even if I had a slick install script, there's still the issue of getting the script and the files it needs onto the empeg. Having a package manager in jEmplode would be sweet!

One feature I'd like to propose is that the package manager have a global config file that it stores on the empeg (perhaps editable remotely via GUI). This could store settings such as:
- default programs directory
- default data directory
- list of all packages installed (editable?)
- Other stuff that I can't think of now, but will seem obvious later.

With a global config file like this, each individual installer can then suggest the user's preferred dir for installation (and most users can just click next). With a list of installed packages, you can have dependencies, or just set settings based on what's available (e.g. emptriv may default to audible if TTSd is installed, else visual).

I'm glad people like the idea. Considering that the people who read this forum aren't the ones who need this application in the first place, I think it has been shown that it's worth doing.

With regard to your suggestions, I have already thought through how to implement every one of them. All of the functionality you mentioned would be included, just in a slightly different form. If you read the original attachment it has a bunch of information about how I was thinking about doing everything. (I've change and fixed a few things since then, but it's pretty similar.) If you'd like I can respond in more detail to your suggestions later, but I need to get some sleep for a job interview now.

The biggest deviation from your suggestions (and it's not that big) is that the config information is saved in a directory called packages that is inside the same directory that JEmplode is installing the applications into. This defaults to /drive0/programs/packages/ and /drive0/programs/ respectively (drive1 is used in some cases). This is of course fully customizable from JEmplode, but is what will happen for 95% of users. The reason that you don't need a different location for a config file is that if an advanced user changes things to a location that JEmplode does not expect, then he is intelligent enough to point it back to the place when he has the info stored. I can go into more detail later.

John

Please tell me you're still working on this! The thread has been quiet for a while, but this is the project I'm most eagerly anticipating. Idiot-proof installs would greatly increase the incentive for the amazing 3rd party apps that are appearing.

Richard
--

Don't panic. People are still dancing around this one, putting all of the little pieces of the jigsaw in place.

No panic here... Would anyone like to give a progress report? I find the whole idea and process interesting...

Would anyone like to give a progress report?

I think the only major hurdle left to overcome is the fact that if you execute a program from the music partition, the partition is considered "busy" and can't be unmounted/remounted, thus screwing up synchs and causing the drive to need to be FSCK'd.

Mark had some ideas about fixing this in the kernel, but I'm not sure whether he's made any progress.

Once that problem is solved, everything else is trivial stuff, and really just comes down to agreeing on standards for a few things, like the file location.

I think the only major hurdle left to overcome is the fact that if you execute a program from the music partition, the partition is considered "busy" and can't be unmounted/remounted, thus screwing up synchs and causing the drive to need to be FSCK'd.

It would certainly be great if we could fix that issue, but it really isn't what's holding us back from implementing a solid application delivery system.[1]

Yes, that's a technical issue that would be nice to have a solution to, but the real reason this doesn't functionality doesn't exist yet (either as a stand alone program, or as part of JEmplode) no one has had the time to implement it yet. Just because it appears easy (for someone with the time and technical knowledge necessary) to install the available applications, doesn't mean it is "trivial" for someone to write a fully-featured system with a decent user interface to automate the process. I'm not saying that this application is all that difficult to create, but it takes a lot more effort than you would think.

I talked with Mike via PMs a few weeks ago, and we both agreed that this is something we'd very much like to see completed, especially given the support that people here have given it.[2] Unfortunately, we both had several other projects "on our plates" and that is essentially still the case for me. I'd still very much like to see this get done, and if no one else takes this up in the mean time I will eventually get to it.

But, regretfully, this project is still in the idea phase as far as I know.

John

[1] For example, to work around the problem, a package format like that attached to my first post above can allow for the author of an empeg program to specify an installation on the root partition, or even better, to specify a list of choice options such as whether to 1) install on the music partition with a DC macro or 2) on the root partition without a DC macro. (Of course, written with having the user having to understand what that means, and having options to override those options.)

[2] While we're talking about things that would be nice to have, I would also very much like to see a MENU_EXEC option. Not that there's anything wrong with siberia37's launcher (I think it's great) but now that hijack has the code to start programs, I think hijack is the right (and cleanest) place for this code.

Yes, that's a technical issue that would be nice to have a solution to, but the real reason this doesn't functionality doesn't exist yet (either as a stand alone program, or as part of JEmplode) no one has had the time to implement it yet.

If the running-apps-on-drive0 problem could be solved, the rest is trivial. You could even code a complete application installer entirely in the DOS batch language with a little help from FTP.exe.

If the running-apps-on-drive0 problem could be solved, the rest is trivial. You could even code a complete application installer entirely in the DOS batch language with a little help from FTP.exe.

I guess we just have different ideas as what the appropriate scope of a solution is then.

The difficulties people have encountered using DOS batch scripts / FTP scripts have shown (to me, at least) that is not really an adequate solution. (Here is one of the many examples of problems that could be avoided.) Things like parsing the manifest file or saving uninstall information or getting user input for dynamic installation parameters or editing the player's config.ini are all unsuited for such scripting. Not to mention that DOS scripting would completely cut out the non-windows users.

I'm not saying that the idea is (technically) very hard to implement, but to write the application the way I envision it would take me more than what I would consider a trivial amount of my time. And I don't think writing a crappy one provides any worthwhile benefit over the scripted installers that are being used now. That said, if anyone does have the time available to code up a decent one, I'd be more than happy to use it

I think you've got the right approach, John. The DOS/batch file stuff is a band-aid, and still requires the user have *some* understanding. I'm not saying that your solution would be 100% foolproof, but I think that jEmplode could *eventually* build in a lot more intelligence and user-error detection than a batch file can.

jEmplode is the one and only best place for this, and I'm glad you guys have it on your to-do list.

The difficulties people have encountered using DOS batch scripts / FTP scripts have shown (to me, at least) that is not really an adequate solution.

Oh, I agree. My point wasn't that it should be done that way. My point was that once that last major technical hurdle gets overcome, the details of an installer are so trivial that they could be done with a script.

It's definitely on the list ... I just have been pretty swamped with some other projects.

ms

I think the missing piece for writing the ultimate installer is the "site exec" command (or possibly "quote exec") from kftpd.. not there yet, currently back behind a queue of about 80 Empeg docks..

Cheers!

Just a little bump here guys... I know Mark is busy, so this isn't really directed at him. Anything that can speed up the process? More than anything I just wanted to bump the thread as a reminder.

Bump again.

Mark, how hard is it to implement the SITE EXEC command? This would be something that I could use right away to code a simple installer for my app, and it is something that I think is very worthwhile in the long term, especially with this installer project.

I don't really know how hard it will be to do.

Gotta try it (again!) to find out. But until SITE EXEC can also learn to return the stdout/stderr back via FTP, I don't think it will be useful enough for me to want to have it in there. Without the command outputs, then when a command fails, the user receives little or no feedback, and then emails ME.

I don't want those emails.

Cheers

Thanks for looking into this, Mark!