[rfc][icedtea-web] fix (And tests) for PR1473

[Jiri Vanek]

On 06/11/2013 03:24 PM, Adam Domurad wrote:
> On 06/11/2013 07:35 AM, Jiri Vanek wrote:
>> On 06/10/2013 10:10 PM, Adam Domurad wrote:
>>> On 06/10/2013 11:24 AM, Jiri Vanek wrote:
>>>>
>>>>
>>>> This patch is removing the redownloading of jnlp file - both from local
>>>> file and form network, and
>>>> so fixing the http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1473
>>>>
>>>> The unhappy redownloading was added during one of inital pushes -
>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/1d604ccd9b6b And I'm
>>>> wondering why:)
>>>>
>>>>
>>>> J.
>>>>
>>>>
>>>>
>>>
>>>
>>> OK this patch left me a bit confused, file.getSourceLocation() is the location of the href, we are
>>> correctly redownloading
>>
>> Is it really correct? It is what is wanted? WYYY!?!?!!? [1]
>>
>>> from here to get the most up-to-date JNLP. However we can skip this check
>>
>> This is 100% wrong for generated jnlp, which have some session id (eg ellumintate). [1]
>>
>> After yesterdays conversation with Omair, I believe that this patch is correct. [1]
>>> based on the update policy, and if we are already downloading from a network location (and we
>>> should, too).
>>
>> Update policy is missuesd in case of forcible re downloaded jnlp [1]
>>>
>>> Your tests seem to fail because the JNLP from the href is attempting to be downloaded -- but this is
>>> correct behaviour. Can you explain ?
>>
>> Yah. My intention was to simulate generated id,and I was to lazy to crate dynamic generation hook
>> in our testing server;)
>>
>> So look into it as that user download GeneratedId.jnlp, where is some value - AnotherId and save
>> it as GeneratedId_1_tmp.jnlp. Then launches this file, but we redownload the GeneratedId.jnlp
>> where is "generated" SomeId, so the parameter id will be suddenly wrong. See the usecases [1] ;)
>>>
>>> Thanks,
>>> -Adam
>>
>>
>> [1]
>>
>>
>> Typical  (correct) usecases I can see:
>>
>> * ./javaws http:/some.remote.url/some.jnlp
>> - best usecase, will have most recent jnlp, and we do not need to redownload (btw I'm sure we are
>> redownloading  even in this case and it is WRONG)
>>
>>
>> * ./javaws somewhere/stored/some.jnlp
>> - imho most common usecase. As user will probably click on the jnlp in browser, and then "open
>> with javaws" (then browser will save it somewhere and lunch the command above).
>> - then redownlaoding is wrong - user already have the most recent version. And if in this jnlp was
>> generated id, session or whatever, it will be lost.
>>
>> * I do not believe user will later dig for  this jnlp file and so lunch the outdated
>>
>>
>> * The only  wrong  usecases I can see after this patch is our jnlp desktop icon.
>> It /points/directy/to/cached/file.jnlp  and so the risk of running outdated one is possible.
>>
>> But it is bug - this desktop file must point to http://original.url/file.jnlp and the offline run
>> must be handled in better way (goal for 1.5 ;) (see [rfc] [icedtea-web] desktop icon is pointing
>> to cache instead to real url and its thread from 1.2.5013 (where you yourself have participated)
>>
>>
>> Thanx for disagreeing:)
>> J.
>>
>>
>
> OK we discussed this more on IRC and I think we're agreed:
> - Don't redownload if no href (already the case)
> - Don't redownload if not local file (needs to be added)
>
> The case where you save the JNLP and immediately launch it unfortunately does redownload, we can
> however do some timestamp check if you really do not like this.
> Other than that ideally the caching system would be allow for a simple HEAD request to determine if
> the JNLP needs to be updated, instead of a full redownload.


ook, try this:)
>
> Cheers,
> -Adam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: correctRedownloadeing.patch
Type: text/x-patch
Size: 19500 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130621/669b2641/correctRedownloadeing.patch