[CLOSED] AppletLoader should provide random UUID per domain

[Matthias]

The AppletLoader should create a random UUID per domain and store this value locally.
This can then be passed via a system property (eg "lwjgl.appletloader.uuid") to the user applet.
An unsigned applet (using the pre-signed LWJGL version from the applet loader zip) can use this UUID to store per user data on the server (like save games).

Optionally the UUID could be different per applet if this is required for privacy reasons or if it simplifies the implementation.

[Matzon]

wouldn't it make more sense that the page serving the applet adds its own uuid for its user?

[jediTofu]

If it just passed random UUID's, two people could end up having the same ID and then two people would be using the same row from the database (although this would be extremely rare).

If have to make unique UUID's, LWJGL does not know what UUID's are already in your database (or on users' file system).

Best option would be to just make a string with datetime(nanoseconds?)+UUID yourself.

Unless I'm missing something more significant here?

[Matthias]

That's all already handled by the UUID class. The chance of a collision is so small that it doesn't matter.

I could use a PHP script (or similar) to create a modified applet page to include such a value and store it via a cookie.
But I would still use a UUID based approach so that I don't need to create a database entry on every page load.
But I'm not sure what PHP has to offer which is comparable to the UUID class - as this class uses cryptographic random generators.

[ruben01]

Generating a UUID on first run is the way the google people recommend for tracking the installation of an android app, so you can store user data on the server, like user config, savegames, etc, exactly the same use case that Mattias is asking here.

The advantage of doing it on the appletloader instead of on the webpage with php is that the work is done only once on the appletloader instead of everyone who wants that feature having to implement that.

One disadvantage of doing it on the appletloader is that if you want your app to be deployed also as a webstart, or a standalone instalation (zip + script, or runnable jar) then you would need to do this in your own code instead of on the appletloader because that is only used on the applet deployment.

[kappa]

just curious, why this feature can't be implemented on the applet that is loaded instead of the appletloader?

[Matthias]

Because an unsigned applet has no way to save that UUID.

[kappa]

Two decent options available these days to save data from Java Applets (without breaking the sandbox)

1) Java Muffins - You get 100kb of local storage. Muffin support is pretty widespread nowadays so pretty usable. Used through JNLP api's.
2) HTML5 Local Storage - You get 5mb local storage and its supported on all modern browsers.

Alternatively we could just add an API to LWJGL that'd give you access to a limited amount of storage (usable from applet or java web start) for example a small class in lwjgl_util.jar.