Yay! I'm back from a busy week and a half of work, so, no, Amos, you didn't scare me away

.
Phhewww

Great !
When I was talking about small files, I was not meaning to say that the COLLADA demo was large. I meant that even though it was small, it still took considerable time to load. And, I am using the Fiber-Optics technology (how do you spell that?), and that's extremely fast.
Actually I do think that the COLLADA demo *WAS* large. And it was due to the fact that I was using XMLBeans, and that the full Xith3D/Xith-tk were included in there, including some unneeded dependencies...
So I expect the following demo to be <300Kb. (240Kb for a jar containing the .dae file + the .png file, + about 40Kb for the code itself... no, less, since this code will be transferred to Xith3D).
For the long loading time, only now I understand what you were meaning. So yeah, the loading time is on some PCs (mostly windows boxes, from what I've tested personally) is awfully slow. Wanna know what's happening during loading ? Every file is extracted to a temporary directory and THEN the app is launched. The extraction is slow that's why the loading time is so long.
This approach will be solved in the following versions (which I'm working on, and really enjoying it). There will be two things you can do with a package :
- Execute it from the jar : Nothing (huh.. maybe excepted the natives.. this will have to be tested, if natives can be used from a jar) is extracted, the
One-Jar classloader will probably be used to load classes/data from jars-inside-jars. Loading time inexistent (instant start), runtime penalty not too important (but still a bit worse than installed).
- Install it somewhere... Which means extract it somewhere and add an icon / launch it if it's executable (e.g. not a library). For where to install it it's still not clear in my mind cause you could put it anywhere as long as you have a file, which you know the location, which contains the path of the program. The question is then where to put the file. In the user home directory ? No, because that would annoy other users of a machine who would want to run the application. I'll search through the java properties to see if a directory is ok with that (maybe the java.home but what if the user upgrades ?).
Do I understand correctly when I think that OneClick automatically installs Xith to your computer, and that if Xith is already installed, then it does not have to again?
Currently, no. In a near future, it'll be like that. In fact you will have the choice.
Either you could include all you need in one, big, fat, jar

(as I did with the first colladademo). Either you could just say "my package includes only what's specific to my game and depends on some other packages". You see ? I want to keep always an "offline" way of doing things, cause sometime people like to play in their rooms where they have no internet... So when a package depends on another, of course it knows where to download it (and to update it, if ever) but it'll tell you what to download by hand if you ask. Which means, to take an example, that the following is/would be possible :
- Guy A. Random Hacker creates a wonderful game. He builds a OneClick package from it (where the hell did he hear of that ?) and makes it depends shamelessly on xith3d, xith-tk, joode, javagamenetworking, and blah blah blah.
- Guy John Player wants to play ARH's game but on an offline PC : he downloads the OneClick package from his site and launch the OneClick package, then choose the menu option "Build an all-in-one install jar" and then it downloads all needed jar and package them. Then John Player copy this file to his PC, install everything and he's fine

- Guy Chris Player wants to play ARH's game too but he has Xith3D and Xith-tk installed on his PC via OneClick. He then choose only to download the missing packages... He chose the option "Download the missing packages" from the OneClick package menu and uncheck Xith3D and Xith-tk, which he already has. The missing files are downloaded in the same place where the OneClick package is and Chris Player can copy them to his PC (without internet) and launch the same OneClick package, choose "Install", and the package will detects automatically 1. that there's no internet connection available, and 2. that the OneClick packages for Joode, JavaGameNetworking and BlahBlahBlah are in the same directory. So it installs everything and Chris Player can play happily, too.
- Guy Bob Player has an internet connection. He goes on ARH's site and discover his game. He downloads the OneClick package, choose "Install" from the option menu, the installer detects that an internet connection is readily available and downloads everything and installs (asking the user first, of course.. you wouldn't install something without its authorization, would you ?), and Bob Player discover's ARH's wonderful work.
- A. Random Hacker releases the sequel to his game, using the exact same technology. The OneClick package is uploaded to his site.
- Our brothers John, Chris and Bob can all play to his game just with the OneClick package on his website, cause it will detect that Xith3D, Xith-tk, Joode, JavaGameNetworking and BlahBlahBlah are already installed.
That's a kind of my ideal vision of a packaging/installer software. It will take some time to come to this point, of course, which is why I go slowly forward.
With a system like that, there is in my opinion no further need for something like Java Web Start. However, I can conceive that some users/devs find it reassuring, to have JWS. Which is why the OneClick package builder should be able to generate the necessary files for a JWS launching of the OneClick package. The dependency system (and updates, and so on) would still be handled by OneClick, not by JWS.
I'd appreciate comments on that, new ideas also, and so on.