[rfc][icedtea-web] https probing
Jiri Vanek
jvanek at redhat.com
Mon Sep 15 11:16:51 UTC 2014
On 09/12/2014 04:53 PM, Jacob Wisor wrote:
> On 09/12/2014 01:26 PM, Jiri Vanek wrote:
>>
>> :(((
>>
>>
>> This patch is becoming blocker.
>>
>>
>> Any volunteer?
>>
>>
>> J.
>> On 09/10/2014 11:42 AM, Jiri Vanek wrote:
>>> ping?
>
> I am on it since yesterday. I am sorry but I have been called multiple times to do something else.
>
> Jacob
Hi!
Thank you very much for the swarm of reviews!
I have read them all and I need to think about them. Again, thank you very much.
Few things which cough my eye:
*localizable Plugin+settings+fix+cleanup:*
the @bold@ whatever@ stuff:
- It is placeholder for <b> in html or \n.B \n in man. Tbh Right now I dont know workaround
- I would like to get rid of of all this @@ markups. And I'm successfully doing so:)
- I Get rid of all except the @bold@, Which I found as necessary evil. But if workaround will be
found. I will be most happy to get rid of it.
>> +IWSexampleL2=Resets the value of `{0}` setting.
> Are the "`" characters literals in the man page or markups?
Originally there were the ' (" ' ") char, however, I noted, then If I put {n} into '' like '{0}' the
properties fiel do not evaluate it correctly. Same for " char and no escaping helped.. So I put
here ` char:(
Anyway - no markup mentioned. In original text it was just quoting - making it readable or similar.
So it have nothing to do with any markup, and AFAIK all plain, html and man output is ok with it.I
will be happy to change it if you dont like it ad know replacement.
https probing
-
> I am absolutely sure we do not want to modify *system* properties for *all*
> future connections here. What about other existing and other future connections,
> especially connections created by a JNLP application?
> And then there SecurityManager implications. What if these or all system
> properties are read-only? So no, we do not want to modify system properties at
> runtime.
Ok. This sounds like serious flaw. My intention was to modify *all* https settings. Actually are
you sure that in this case I'm modifying jnlpapplications one? Reading it now.. you are probably
right:-/. - but - ITW is creating copy of the properties, and to jnlp app it is forwarding the copy
of original one. However, thank you for catching this. This needs verification/investigations on my
side.
If I leave aside the affect on future running jnlp app, and cosidering only impact of itw, then this
what this patch should do.
- got requested https connection creation
- stop the world
- try to set working https configuration
- create connection and use this setting sinc on for ever (no stop the world anymore)
or (if probing always and/or synchronized connections on)
- got requested https connection creation
- stop the world
- try to set working https configuration for this single run
- create connection. In next request do the same
The motivation to do this was:
- 99% of applications need same https settings for whole app (I mean jnlpruntime, not the
application itself)
- the 1% which needs to connection to different not-standard servers wil need to use the second
approach.
IcedTea-Web for Windows
ico:
commandline "convert" tool from imagemagic package do nit suit you?
>> I would go for something like
>> plugin/windows/src (your "c a nd rest" files)
>> plugin/windows/build (mingw make or whatever you may need for build (the ico if
>> you will insists?-) ) ))
>> plugin/linux/src (current icedteanp)
>> plugin/linux/build? And so extract plugin parts from main makefile?
>> plugin/share/java (current current java)
>> plugin/share/docs
>> plugin/share/tests
> Yes, this reads reasonable. However, I am going to do this for Windows now only.
> Moving the Un*x/Linux sources will require adapting the build scripts to the new
> file structure or things will break. So, I do not want to touch the Un*x/Linux
> sources now because it is going to take a changeset of its own.
I think that the adaptation of current makefile will not be so dramatic. And I think it is better to
do it earlier or later
All those are more over thoughts, I will probably copypaste them to next rounds of review, but all
seemed to interesting to dont reply:)
Again, TYVM for reviews!
J.
More information about the distro-pkg-dev
mailing list