[rfc][icedtea-web] reconsider offline and xoffline

Sat Feb 21 18:13:24 UTC 2015

On 02/18/2015 06:30 PM, Jiri Vanek wrote:
> On 02/13/2015 02:54 PM, Jacob Wisor wrote:
>> On 02/13/2015 um 02:17 PM, Jiri Vanek wrote:
>>>
> ...
>>>>>
>>>>> What about honoring it only in strict mode?
>>>>
>>>> AFAICT, strict mode is supposed to check only the syntax of a JNLP file a bit
>>>> more vigorously. So it
>>>> is about syntax, not about runtime or application behavior.
>>>
>>> I would rather say "it is forcing itw to be as close to specification as
>>> possible" . But yes,
>>> originally it came in as parser settings and you are right that any other
>>> misuse of it is beyond
>>> this patch if possible at all.
>>>
>>> But playing with words - strict is moreover ok here - it pretends the element
>>> offline-allowed do not
>>> exists.
>>
>> If it is really bothering you that much and you really want to have it in
>> IcedTea-Web then I would
>
> Id really does :(
>
>> rather propose making it a specific feature of IcedTea-Web and therefor
>> introduce a -offlineAllowed
>
> That wuld kill my point. Now the -Xoffline is solving this, but people are still
> asking me, why it is not going offline, I reply put -Xoffline to commandline,
> Then I got What is commandline? And at the end it somehow ends in .desktop
> launcher:(
>
> SO Iwould like to have this behaviour default, but enble-able.

So, there you go, as I understand we already /have/ the "-offlineAllowed" 
functionality implemented in IcedTea-Web and people are still complaining. And, 
if people are complaining because they do not know basic things about computing 
- like what a command-line is - then they should definitely not ask about things 
that violate the specification or override the specified behavior in a JNLP file.

As I already have said before, and you probably have explained to some users 
too, one has two options:
1. Modify the JNLP file to suite one's needs or
2. use the -Xoffline switch.
Now, if you want to make it "dump-user-compatible" then IcedTea-Web would need 
to keep track of all JNLP applications ever downloaded or launched, and offer a 
GUI controlled configuration set for everyone of them. This leads to a lot of 
followup problems.

The simplest of them would be figuring out what happens when the user clears the 
cache. Do the configuration sets persist or do they get deleted too?

Next one: What if an application gets moved to another codebase? Does 
IcedTea-Web keep track of that? You know, because some people are going to 
expect the same behavior for an already configured JNLP application as before. 
The JNLP specification does not provide a means for uniquely identifying an 
application, except for its name, version, and codebase but this is probably not 
enough and some corner cases will be found sooner or later.

But the biggest problem comes with JNLP applications that have been downloaded 
incomplete or those which really rely on online connectivity. There is simply no 
way for a JNLP client to know whether an application has been fully downloaded 
or absolutely relies or online connectivity except to trust in the proper 
presence or absence of the offline-allowed element in the JNLP file.
Oh man, I can already smell the trouble coming; people are going to complain why 
their supposedly offline-configured application does not work, since they indeed 
have explicitly configured that particular application to work offline. Ugh, I 
can only imagine the anger. This will lead to insane discussions with support 
representatives. Again, offline capability is defined by the author of a JNLP 
application (and the author of the JNLP file, although a publisher or user may 
still change it at their own risk) and no one else. Period. If people add the 
offline-allowed element to a JNLP file or launch IcedTea-Web with -Xoffline then 
they are doing so at their own risk. If they want a properly working offline 
application then they should contact the author of that application. This is 
probably also the reason why offline-allowed is not the default in the JNLP 
specification. There is simply no way to determine this automatically.

Oracle's Java Web Start JNLP client does keep track of un-/installed 
applications, however it does not allow for configuring applications' 
offline/online mode because AFAIK it only installs applications with the 
offline-allowed element specified in their JNLP file (I know this because once I 
had to author an orchestra of JNLP files to deploy Minecraft with all of its 
dependencies in a classroom environment). So providing the un-/installing 
feature would be the best we could/should do.

>> switch. Please do not mix this with the semantics of the -strict switch. This
>> way both
>> functionalities can be used together or separately. The -strict switch should
>> be left for /strict/
>
> oook.
>
>> /syntax/ checking only. I think IcedTea-Web (actually every software) should
>> always follow the
>> specification as closely as possible by default.
>>
>>>> There is really not much we can do here except to seek for a change in the
>>>> specification. But is
>>>> this really worth the cause? Maybe. But, it won't be before the release of
>>>> Java 9 or Java 10 this
>>>
>>> :) 6 years?  It is hard to imagine universe beyond this time ....
>>
>> I know what you mean, especially when you look at the time it took to get from
>> Java 6 to currently
>> Java 8. But you also have to take the fallout of the economic repercussions on
>> the OpenJDK
>> developers of Sun's dissolution/merger with Oracle into account. Since Java 7,
>> it seems like the
>> Java world has got back on track again. However, Java did not really benefit
>> from this, especially
>> in the mobile sector, which is quite unfortunate. Well, this is what happens
>> when people simply buy
>> into a technology they do not understand ... but this is a story for another day.
>>
>> Anyway, you could propose an update to the JNLP specification at the JCP. It's
>> open, isn't it? ;-)
>
> Looking to the enthusiasm they listen to not oracle people...:(
>>
>>>> would come into effect. If some users are having trouble with incorrectly or
>>>> sluggishly authored
>>>> JNLP files then they should either contact their software vendors,
>>>> administrators, or edit the JNLP
>>>
>>> And if those authors are gone? Afaik this is the main user space of javaws and
>>> plugin now :(
>>>
>>> I'm adding those out-of-specification stuf only when I'm asked for. And for this
>>> I'm askaed for few
>>> years... And here I  Agree from hart - why to force the app run online, if it is
>>> fully capable to
>>> run offline?
>>>
>>>> files to adjust to their needs (because the location of the JNLP file itself
>>>> does not matter). I
>>>> think it would be no good if we would simply abandon the specification. Let's
>>>> use the time and
>>>> effort for something more productive, like implementing parts of the
>>>> specification IcedTea-Web is
>>>> missing. ;)
>>>
>>> Which are those you miss the most? I stopped tosearch for them, because i
>>> stopped hearing complains
>>> (but maybe its just become low usage of ITW)
>>
>> AFAICT, all the stuff about properly installing/uninstalling (with
>> dependencies on non-app JNLP
>> modules) and managing applications is missing. I may be wrong because I have
>> not been able to follow
>> IcedTea-Web's development more closely lately. But you seem to have added
>> support for installing
>> desktop links or something like that, so it is slowly moving into the right
>> direction.
>
> This is something I'm trying to do with offline+cache+desktop_integration. I
> think I'm on good way in this.
>
> I have also some proof of concept about managing those applications via
> itweb-settings but it needs     some more adaptations.
>
>
> My idea why to use cache+offline for install is that it is already done. And itw
> consider application as installed when it is able to run, and that means
> unpacked in cache.
>
> Except this "reconsider offline" it needs few more tweeks to the cache so it do
> not invlaidate so quickly.
>>
>>> My most painful thorn are     caller allowable, trusted library,....
>>
>> I do not understand what you mean by "caller allowable trusted libraries". ???
>
> Those are two "new" (introduced year ago) security manifest attributes. Itw is
> still not honoring them
> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html
>
> Entry-Point Attribute on the way, rest done,  but those two... Still no op.
>
>>
>>>>>> Or rather specify semantics for an online-denied element. But this is has to
>>>>>> be defined by the
>>>>>> specification, not the implementation. Otherwise we could just start
>>>>>> assigning
>>>>>> our arbitrary
>>>>>> semantics to every arbitrary aspect of the specification. This would
>>>>>> certainly
>>>>>> be neither wise nor
>>>>>> helpful to anybody in particular.

Regards,

Jacob