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

[Jiri Vanek]

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 stric mode?

> 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");
>>>       }
>
> Regards
>
> Jacob