Deprecate / remove java applet for large download ?

[jcfr]

While trying to download 1.8GB from http://aladdin.kitware.com (Midas 3.2.11), after clicking on the download link for a folder, I am proposed two options. See screenshot below.

As suggested, I have clicked on the "Yes, use large downloader". Then, on windows:

1. firefox asked me to manually install Java because of security reasons
2. after following the instruction, I managed to install java
3. going back to the page, the applet failed complaining the current security settings can't accept self signed certificate
4. I then added a security exception (Start menu -> Programs -> Java -> Configure Java -> Security) by listing http://aladdin.kitware.com as an exception
5. going back to the page, I was able to see the applet ... clicking on Download failed with a timeout

Finally, I gave a try with the normal downloader .. and already 0.5 GB have been downloaded

Moving forward, I suggest we disable the java downloader. It should be enabled explicitly on instance that require it.

[mgrauer]

I've had problems using the Java uploader and downloader on my Mac, and supporting these is difficult. I suggest we deprecate these and recommend they be turned off in instances.

At least for the uploader there is a great alternative in that the HTML5 uploader works well.

[zachmullen]

👍

Java applet support is all but dead, especially if you don't have a verified cert. We don't need it for uploading anymore, and for downloading we can do what S3 and other hierarchical key-value stores do and just provide a command line interface (i.e. pydas) that will download a hierarchy with resume functionality.

[cpatrick]

I hate Java applets so much. We should move to disabling them by default anyway.

[cpatrick]

[jcfr]

@cpatrick Nice one

Excellent. We all agree on this.

I would suggest we come up with a timeline, when is the next midas release plan ? May be we could create a blog to explain our choice and what are the alternative way for downloading directory structure ?

[jamiesnape]

It is all in a separate module now, so you can easily disable it, or we could just delete it without impacting the core.

I am going to try to get the last handful of commits in by the middle of next week, so the version 3.4 codebase should be finalized around January 15.

[jcfr]

+1

Sent from my mobile device
On Jan 8, 2015 10:05 AM, "Jamie Snape" [email protected] wrote:

It is all in a separate module now, so you can easily disable it, or we
could just delete it without impacting the core.

I am going to try to get the last handful of commits in by the middle of
next week, so the version 3.4 codebase should be finalized around January
15.

—
Reply to this email directly or view it on GitHub
#82 (comment).

[jamiesnape]

I will sign the jar before release, so at least there will be slightly fewer warnings.

[jamiesnape]

Rolling this ticket into #71 regarding the signing of jars.