Deployment - web based install

[Igor Nekrestyanov]

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
>>