I'm on it. Here's one idea

1) App developers ensure that their application's files are live in an application level directory - ie mygame has all neccessary files in the directory /somedir/mygame/ and not just in /somedir/
2) .tgz files are created of this directory, not of the files. so when we untar mygame-0.1.tgz into /programs0/ the directory /programs0/mygame/ gets created, and all the files put there.
3) Included in this tarball is the file /mygame/empeg_install.sh which contains some variables eg:

#!/bin/bash
#install.sh
export PATH = mygame
export BINARY = mygame/mygamebinary
export PRIORITY = M99


4) JEmplode installs and execs a script that sets a lot of stuff up - formats /dev/hda2, modifies /etc/fstab, creates a couple of mounting utilities, and installs a couple of scripts; /etc/preinit.d/N10mount and /etc/preinit.d/M0appinstall.
5) JEmplode installs the preinit binary.
6) JEmplode modifies config.ini to ensure that reservecache is set to a sensible value.

7) At this point users can ask JEmplode to dump an application tarball into the empeg. JEmplode puts it in a known location...eg /programs0/new
After a reboot, preinit finds it's first 2 scripts. The first one mounts the /programs0 partition ro. The second script, M0installapps.sh checks to see if there are any tarballs in /programs0/new/. If none exist, it exits. But if there are any, it untars them into /programs0. It then sources the empeg_install.sh script contained in the tarball, and uses the information found there to set up /etc/preinit.d/ entries Finally it moves the tarball so it doesn't get found next reboot... eg to /programs0/installed


Issues:
There wouldn't be any feedback on the final install process. For the whole part this isn't a huge problem, as most stuff will untar almost instantly, and the application will be ready for use next boot. But emptriv takes an exceedingly long time to untar because of the huge number of question files. I don't see an easy way around this problem. Yes we could make JEmplode do the application install itself, but this would either require telnetd to be installed and run so that JEmplode can run commands natively and get decent feedback, or kernel changes to allow JEmplode to achieve the same thing through the ftpd in hijack. Neither is really a desirable solution.
(I'm happy running telnetd on my empeg because it never gets plugged in anywhere but my home network - but those of you plugging in at work should *not* run it in it's current state - there's no password protection (and it would be sniffable anyway), and it has full root priviledges, meaning that anyone could scrub the entire drive(s)).
The ideal solution would be for emptriv to consolidate the questions into a few much larger files, and seek to position within it when looking for a question. But I understand that this would also be a pain to do.


Opinions?