Deployment - web based install

[Daniel Zwolenski]

Hey Igor,

Great to get a discussion going on this again. It's no easy task I'm sure - the challenge of cross-platform is at its worst in this launching area. 

What you describe as the "thin app" is definitely what I am referring to. The "fat app" is equally valid but I feel if thin app worked well, it would be better than fat (others may disagree). As such, I'd be keen to workshop/discuss just the thin app options first and see what we end up with, fat app then being a fallback topic if we think thin can't get us there. (and fat is needed for a pure offline mode to be discussed later). 

Thin app is what webstart is aimed at. The goals of webstart are inline with what I'd consider the ideal. Webstart falls down in the implementation. Webstart is suppose to make the app installation easier (and it does) the problem is installing webstart (ie java) is confusing, scary and requires manual steps that are error prone (eg choosing 64bit vs 32bit). 

My ideal scenario is in essence making the browser plugin replace webstart so that webstart doesn't have to be installed. The job of 'prelauncher' or 'bootstrapper' that webstart normally does would move into the plugin totally. Since a browser plugin can be installed with a single click and since we're not installing java at this point (so we don't need disclaimers, or other dialogs) this first step can be quick and simple.

I'd then see the browser plugin reading the deployment descriptor (whether that's jnlp or something else) and from this determining which min (and max) version of java is needed. The plugin can then search for an appropriate installed version and if found use it. If not found the plugin then downloads and installs it. Note: I see no reason multiple jre's can't be installed on one pc in this approach, so if an app is fixed to an older version, no worries. There is no need to force upgrades in this model (I realize applets need this, but if that's a problem then we could explore this, eg the applet jre is seperate to the system one and only used for applets). This is an area for more exploration anyway. 

Then jfx is installed if needed and finally the app is installed, shortcuts are added, etc and finally the external java process is spawned. All this is done by the plugin in one smooth, minimal-dialog process as described. Future launches don't use the plugin, they can go to java direct since we can be sure java is installed then (a native pre-launcher could be used to check for new releases still). 

I don't know enough about plugin development/restrictions to know whether this could be done (ie download files, install stuff, search/update the registry, add shortcuts, etc). That's probably the biggest (only?) technical hurdle that I can see. Putting aside questions of whether its a good idea, do you or anyone know if this is technically feasible - if not then this idea is dead in the water and we can save time discussing its merits and faults. 

Obviously building this plugin is not going to be trivial. Every OS needs different stuff and every browser needs different things. It's messy. But if it's possible, it would be worth it. We the community can help too if needed. The problem we have is that legally we would not be allowed to develop this because of the jre (and jfx) licence. Otherwise I'd seriously consider having a crack at it for windows and chrome. 

Regarding signing and permission. Firstly, if the user can't understand the permission they are granting then there is no point them being asked. My suggestion is to identify the permissions the user would care about (there are probably less than 10) and then the plugin would map these to the appropriate java system permissions. 'threads' is a great example. There is no point restricting this, and no point asking the user. These permissions exist for reasons way outside our desktop app scenario here (eg thread restrictions might be used on a shared server instance). 

I'd guess the permissions would be along the lines of;
- read files from your computer
- write/edit files on your computer
- make network connections
- launch other/native applications or utilities

There might be a couple more (community?) but not many. Each of these may map to a dozen java permissions, etc, and there will likely be a bunch we don't even need to ask about (eg creating threads). The plugin would configure the spawned JVM appropriately based on the users high-level selections. 

It's worth noting that this simple permission system would still be a big plus over a normal install. I was never asked if MS Word for example was allowed to save files or download clipart. This a web concept that has leaked across here but been built on a low-level sys admin model. It's not a bad idea but we need to keep it simple. 

Regarding identifying the developer with a certificate. The user just typed in the URL zenjava.com. They either trust that or not. If they don't trust that URL, they aren't going to feel any better when the dialog pops up and says 'Zen Java'. If they go to www.dailyhacker.com and then install a java app from there that says it comes from zenjava then they will get burnt. That's the way the web works, it's the same for Internet banking, Facebook and online shopping. Sure we could be more secure than this but so could every other platform. There's a balance to be met between security and ease and the competitors out there are much more on the 'ease' side of things than java making us less popular even if we are more 'safe'. 

That's some further thoughts anyway. I definitely don't feel I have all the answers here and there's heaps to work through. The goal is getting the users onto jfx as quickly, painlessly and as near to as invisibly as possible. Happy to be shown up by people with better ideas out there!

Looking forward to hearing responses. 
Dan



On 24/04/2012, at 4:03 PM, Igor Nekrestyanov <igor.nekrestyanov at oracle.com> wrote:

> Hi Daniel,
> 
> Thanks a lot for your input!
> (Changing subject to keep this part of discussion focused on "web based application install scenario".)
> 
> Many ideas from your ideal scenario had been discussed earlier and we are constantly working on improving UE
> but it certainly clear we are not perfect and worth to have another look. We want to do better.
> 
> First few things i want to provide some details and get input/clarification on are:
> 
>   1. Content of "application package"
> 
>       Sounds like in your description we have "thin" application that has external dependency on specific runtime (JRE+FX).
>       Runtime is to be provided by Oracle and installed as public runtime on the system.
>       This similar to what webstart/JNLP supports except
>             a) your description has fewer dialogs
>             b) dialogs are integrated
>       (in fact with Deployment Toolkit we do have some of described functionality)
> 
>       Pros of this approach as i see them:
>           - application package itself is platform independent
>           - reasonable download size for those who has JRE/FX
>           - can trust "runtime" before we download all of application
> 
>       Cons:
>           - hard to ensure compatibility as environment can change (one version of JavaFX can be installed and user may upgrade it)
>           - additional dialogs may be needed to "elevate" permissions
>           - hard to install system JRE/JavaFX on different operating systems
>               (e.g. flavors of linux, etc.)
> 
>       One possible alternative is to distribute "fat" application that includes own copy of JRE and this runtime is only used for this application.
> 
>       Pros:
>          - "package" is self contained and preserves application compatibility
>             (this is how things will work for distribution via App Store, etc.)
>          - can be installed into user space (e.g. cache) => easier to support cross platform
> 
>       Cons:
>          - Much larger download size
>          - Can not "trust" cobundled JRE/FX until we validate application package and user accepts he ok to run it
> 
>    2. Signing & Permissions
>>     Installing "Daniel's cool application"
>>     Developed by Zen Java (more info...)
> In order to be able to show this application must be signed (otherwise everybody can pretend to be anyone else).
> Currently signing the application & requesting all permissions are very tightly coupled but it is not necessary should be the case.
>>     Java will be installed to run this application (more info...)
>>     This program requires the following permissions:
>>         * Read and write files on your computer
>>         * Make network connections
>>     [x] Add shortcut to start menu
>>     [x] Add shortcut to desktop
> I wish we could make it this way (and this had been discussed so many times ...) but this part is complicated due to granularity of java security model.
> Shortcut creation and java installations are actions outside of security model and it is possible to handle user choice in the deployment code.
> But "other" permissions will likely be too complicated for end user, e.g. "launch new threads"?
> Typical "signed" application indirectly uses many of them.
> 
> Security model is being revisited for JDK8 (not sure if it is commited or TOO) and hopefully this will open more opportunities for finer granularity of security questions.
> 
>    3. "Smart install" plugin
> 
>        In fact we do have "additional" plugin that is capable of validating and installing JRE and JavaFX if they need to be installed (since 6u10 or so).
>        However,
>           - it is windows only and implementation for other OS might be not trivial (and it is a lot of native code)
>           - it is shipped with JRE (or JavaFX)
>           - only JRE7+ have version of this plugin that knows how to install JavaFX Runtime
>           - it does not download the application itself
> 
>        Personally, I like the idea of distributing such plugin through regular browser plugin distribution channels.
>        But i am not "sold" on all functionality you described.
>        Some random thoughts/doubts:
>            - Can not use java => lots of native code.
>                From old plugin experience we know this leads to more robustness and security issues (java based implementation make it easier to avoid them)
>            - Described functionality can essentially install arbitrary package. There is no real java dependency.
>               And for this there could be OS or browser specific solutions. E.g. ClickOnce from Microsoft or .dmg on Mac.
>            - Supporting "generic" application complicated implementation as application may require different things, e.g.
>                 different types of signing certificates, update check logic, cache management, etc.
>                 Focusing on "fixed" set of possible packages (e.g. JRE packages only) make it easier to develop and test.
>            - Ideally we want solution that supports other deployment scenarios as well (not just with this plugin but
>                 we want things to play nicely together)
>            - if we are talking about WEB-browser based installation we do not necessary need to install everything in one process.
>               UI can be shown in the browser using javascript => it can "appear" to be the single process ...
> 
>       IMHO, it could be possible to simulate similar experience (on Windows) with existing blocks after some tweaking of them
>         if we assume that a) DT plugin is preinstalled, b) not blocked by the user, c) JavaFX is part of JRE (as standalone JavaFX
>           installer has too many dialogs on its own)
> 
>    4. 32 vs 64 bit system
> 
>        In general i fully agree this need to be transparent to the user (and most of developers unless they ship native code).
>        Just want to mention it is not trivial problem because 32 bit and 64 bit environments on the same system can differ significantly.
>        E.g. JRE versions may be different or user might only have subset of 32 bit GNOME libraries installed (and full set of 64 bit) on his linux desktop.
>        Detecting what is available and operational might be hard.
> 
>    5. Java update checks
> 
>        On demand update checks are not perfect:
>            - can not guarantee system is not vulnerable as it may be way out of date as user rarely uses java and
>                   what he runs first might be malicious applet
>            - mandatory check on startup may be huge performance hit
>            - update may require relaunch and it technically is not trivial (might involve relaunching of the browser process, etc.)
>               "Updating" binaries that are currently used on Windows is hard.
> 
>        I am not trying to say these types of update are useless. We are exploring this option too and Mac plugin drop will be using this update strategy.
> 
> -igor
> 
> On 4/20/12 8:21 AM, Daniel Zwolenski wrote:
>> Below are the three major deployment scenarios I believe we'd like to have in our arsenal. Please add/correct based on your opinions.
>> 
>> 1. Web-based install of desktop app
>> 2. Web-based launch of Applet
>> 3. Offline distributable of desktop app
> We also see demand for web based launch.
>> 
>> For all of these I believe we want a single, minimal-click, minimal-dialog process that installs (if needed), the JRE, JavaFX and the custom app being run. It is not three installs or even two to the user, they are installing one thing only - my custom app. The fact that Java or JFX is needed is not something they want to be overly bothered with. One, end-to-end, simple seamless flow is what the users want.
>> 
>> I'll get the ball rolling with my view of the ultimate flow for option 1. In this scenario we are trying to achieve a pretty similar experience to what you get when installing an app on a smart phone. Currently webstart is the closest thing to this but it has the flaw that Java needs to be manually installed first. I suggest a plugin that does a smart install of everything. This plugin may well need to be different to the 'applet' plugin, I'm not sure. If it does however, so be it.
>> 
>> As with normal webstart (and smart phones), option 1 is not so much a webapp as a web-based 'install' of a desktop app - once locally installed it can run offline.
>> 
>> Here's the sort of flow I'd like to see if the user doesn't have java installed:
>> 
>> - User navigates to the URL for the app in their favorite browser
>> - Browser Plugin is triggered
>> - Dialog 1: browser's standard, "do you want to install plugin"
>> - Plugin is installed and runs
>> - Plugin searches for existing JRE, finds none
>> - Dialog 2: says:
>> 
>>     Installing "Daniel's cool application"
>>     Developed by Zen Java (more info...)
>>     Java will be installed to run this application (more info...)
>>     This program requires the following permissions:
>>         * Read and write files on your computer
>>         * Make network connections
>>     [x] Add shortcut to start menu
>>     [x] Add shortcut to desktop
>> 
>> - User hits 'Install' (or 'Cancel' to abort)
>> 
>> - Dialog 3: Combined T&C page for Java + JRE + my custom T&C (preferably one dialog with sections, or as close-to as legals will allow)
>> 
>> - Plugin detects system (not browser) OS and 32 vs 64bit (don't ask user, 90% don't know)
>> - JRE+JFX is downloaded and installed (no further input dialogs shown, just a progress indicator)
>> - My custom jars (and any relevant bundled native files) are downloaded (same progress indicator as when installing jre)
>> - Shortcuts are added to the relevant places
>> - Final dialog: Daniel's cool application is now installed. Would you like to launch it now?
>> 
>> From this point on, the user can launch the app from the start menu. A browser is no longer needed (or wanted). Ideally when the app is run it first checks for a new version of Java, JFX, or the custom app online and gives the user the option to upgrade (I feel they should be able to decline). This check is done now by a local pre-launcher, ie the browser/plugin is not involved from here in.
>> 
>> As far as signing/permissions, I think it needs to be simple. Permissions should be selected by the developer and listed for the user in the same simple approach that smart phones use (eg "write to files on your computer"). Getting a digital certificate is a pain so if there was a way to avoid this or an easier way to do this it would be great - bonus points.
>> 
>> I would very much prefer it if the automatic Java updates weren't going on all the time in the background. It would be best if the version was just checked on app startup and the user given the option to upgrade. Then they have context. The random 'update your java now' dialog that pops up add-hoc freaks out most users and makes the others angry (including me!)
>> 
>> If in the above flow, a suitable version of java or jfx was found, then the flow would be the same. The difference would be only that on the second dialog, instead of saying "Java will be installed" it says "Using already installed Java" and the 'more info' link then shows details on where it's installed, etc. Then the T&C section would just leave out the Terms for the already installed stuff. Similar if the JRE/JFX needs to be upgraded.
>> 
>> That would be the optimal UE for option 1 for me. I'll stop there to see what kind of response this gets but options 2 and 3 would take similar tacts.
>> 
>> I'm interested in hearing from the JFX guys what would prevent this from being implemented. Why cant we have this? Are there technical limitations, do you disagree that this is important or would be a better flow, or is it just too much effort?
>> 
>> Just as importantly I'm interested in hearing from all the developers out there. Is this your ideal scenario, is this important to you etc? I raised this issue months ago and the response from the jfx guys was that non-applet, seamless install was too small a use case to warrant the effort needed. I didn't hear anyone chime in to the contrary back then so I don't blame the JFX guys for not moving much in this space.
>> 
>> Get vocal (on solutions, not just problems). If you want something like the above, say so loud and clear. If you want something different, say that even louder so the rest of us can consider that too and back it if appropriate. There's a top notch team and community at the ready here and for my money this is a make-or-break issue. Let's work this one out together.
>> 
>> Cheers,
>> Dan
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20/04/2012, at 2:32 PM, Igor Nekrestyanov<igor.nekrestyanov at oracle.com>  wrote:
>> 
>>> On 4/19/12 11:03 PM, Tom Eugelink wrote:
>>>> Ok. How about the "there is no standard way to distribute a stand alone JavaFX application"? Create a JIRA issue?
>>> Could you please be more specific?
>>> 
>>> What is "standard way" and how do you expect to distribute this package?
>>> Is it different problem from distributing java application (especially once javafx runtime will be part of the JRE)?
>>> Do you expect to application "install" on the user system or run from the package?
>>> Are you thinking about shipping your application to the App Store?
>>> 
>>> We might have related feature request already:
>>> http://javafx-jira.kenai.com/browse/RT-19446
>>>    "Add ability to co-bundle Java + JavaFX + App into a single native executable"
>>> 
>>> It is on 2.2 list right now but it is not clear if we can support other native packages for platforms other than Mac yet
>>> (see discussion in the JIRA).
>>> 
>>> -igor
>>> 
>