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

[Jacob Wisor]

On 02/13/2015 um 02:17 PM, Jiri Vanek wrote:
>
> Forgot to cc distro...
>
> J.
>
> On 02/13/2015 01:18 PM, Jacob Wisor wrote:
>> 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.
>
> 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 rather propose making it a specific feature of 
IcedTea-Web and therefor introduce a -offlineAllowed 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/ 
/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? ;-)

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

> My most painful thorn are     caller allowable, trusted library,....

I do not understand what you mean by "caller allowable trusted libraries". ???

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

Jacob