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

[Jacob Wisor]

On 02/13/2015 11:35 AM, Jiri Vanek wrote:
> On 02/13/2015 11:26 AM, Jacob Wisor wrote:
>> Greetings!
>>
>> On 02/13/2015 09:46 AM, Jiri Vanek wrote:
>>> On 02/10/2015 04:14 PM, Jie Kang wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> Currently the offline environment of ITW is not perfect
>>>>>
>>>>> Applets in browser works even when network is off -its good.
>>>>>
>>>>> Also all jnlp apps works offline, unless offline-allowed is missing. Same is
>>>>> for -html switch, because
>>>>> pluginbridge by default do not specified it. If -Xoffline is specified, then
>>>>> this check is not done,
>>>>> and all -html applets an javaws apps without offline-allowed  works.
>>>>>
>>>>>
>>>>> I would like to remove all possible checks of it.
>>>>>
>>>>> Most direct approach is attached. But maybe better one to remove all usages
>>>>> of isOfflineAllowed may
>>>>> be better (but then the comment is lost)
>>>>>
>>>>>
>>>>> Thoughts?
>>>>
>>>> Hello,
>>>>
>>>> What happens to applets that only want to run 'Online'? You say 'Most
>>>> applications are misusing it' but what about those applets that
>>>> include/exclude the parameter correctly?
>>>
>>> They will fail later with regular exception. So imho it is correct behavior.
>>>>
>>>> In your opinion, how does this change help? I feel like the original is still
>>>> okay.
>>>
>>> Nope. Currently you need to force Xoffline to achieve it. (except regular
>>> applets
>>> in browser)
>>>
>>> However, year with xoffline proved me to be right. Apps were nearly always
>>> forbidden to run offline without any reason, and were working fine.
>>
>> This sounds like "Oh, some application developers are unable or unwilling to
>> author correct JNLP
>> files, so let's change the specification". I think IcedTea-Web should follow
>> the semantics of the
>> specification for the offline-allowed element. In fact, it should follow the
>> specification on every
>> aspect. Just because some applications can or could run flawlessly offline but
>> for some reason
>> shouldn't, does not mean we should silently deviate from the specification.
>> There are good reasons
>> for the semantics of the offline-allowed element. Well, the only thing that
>> could use some critique
>> here is the fact that
>> offline-allowed should have been made to be defined implicitly instead of
>> explicitly in JNLP files.
>
> I agree with you, and most  of all with "offline-allowed should have been made
> to be defined implicitly instead of explicitly in JNLP files".
>
> However - can we change it? No... Can we bound it? maybe...
>
> 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.

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 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 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. ;)

>> 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.
>>
>>>> If anything, I think removing the usages would be better. You can still keep
>>>> the comment inside InformationDesc. Something like:
>>>
>>> I dont think. It is quite wides spread, and before 1.6 goes out, maybe we
>>> reconsider. So I would rather use return true, and kept usage s for a while.
>>>>
>>>>       public boolean isOfflineAllowed() {
>>>> +        //WARNING: Icedtea-Web ignores this parameter. Most applications do
>>>> not use this correctly.
>>>>           return null != getItem("offline-allowed");
>>>>       }