[rfc][icedtea-web] policytool in itweb-settings
gitne at gmx.de
Tue Jan 21 09:29:15 PST 2014
On 01/21/2014 05:52 PM, Andrew Azores wrote:
> On 01/21/2014 11:29 AM, Jacob Wisor wrote:
>> On 01/21/2014 04:09 PM, Andrew Azores wrote:
>>> On 01/20/2014 06:19 PM, Jacob Wisor wrote:
>>>> On 01/20/2014 01:27 PM, Jiri Vanek wrote:
>>>>> On 01/17/2014 10:08 PM, Andrew Azores wrote:
>>>>>> On 01/17/2014 11:52 AM, Jiri Vanek wrote:
>>>>>>> Not sure if we will backport this, but probably yes.. Depends on final
>>>>>>> ok. Ok to head, and please elaborate on backport to 1.4 it is worthy.
>>>>>>> Also please fix the closing of window asap (as new chngeset)
>>>>>> 1.4 doesn't have DirectoryValidator... what should we do here then? Also
>>>>>> DirectoryValidator? Or just let the 1.4 backport have less of a guarantee
>>>>>> the policy tool will
>>>>>> be able to successfully launch, and try to provide useful errors if not?
>>>>> Dependes on you. I'm for *not* backporting the directory validator, and live
>>>>> with "maybe not readable file". But also I would just ensure the parent dir
>>>> :-o Nooooo, please do not backport this! It is actually a new feature, so it
>>>> should rather go into the next minor version release.
>>> I'd agree with you if there was actually any work done to support custom
>>> policies in the classloader or security manager or anything like that,
>> Right, there is none, so introducing that kind of or similar support is a
>> topic of its own. From the user's (and design) perspective , it does not
>> matter whether this additional "security feature" is implemented internally in
>> the one way or the other. The effect is important.
> My point is that the support is already there. The security feature currently
> exists. The implementation is complete. There is no topic needed for the
> introduction of support, because that has already passed.
>>> but this
>>> is really just a minor cosmetic addition to the control panel. I think that's
>>> acceptable to backport (assuming no work to add support is required).
>> It is beyond cosmetics. The gravity of added functionality in software
>> engineering is not measured by the amount of buttons or what ever UI controls
>> newly introduced to an existing UI. It is rather measured in the amount of
>> *functionality* and the *consequences* there of, hence the effects.
> This patch introduces no new functionality. PolicyTool already exists, as does
> the implementation making use of policies on the system. The only thing this
> patch does is add a button giving users an easy way to launch PolicyTool with
> the correct file path presupplied. Exactly which consequences are you talking
> about, here? I really do not see what negative impact there will be from adding
> one button to the control panel - a button that does absolutely nothing new
> other than provide a convenience.
I am not talking about technical effects. I am talking about effects on support
staff and admins. They may not be familiar with J2SE's policy system yet when
their user's and customers start calling in for help. You know, it is not
uncommon for large organizations that provide in-house support to have their
staff (really, this does sometimes happen indeed!) trained for a specific set of
applications and thus features. They truly rely on specific feature sets and
incremental evolution of software. Of course, this feature will probably not
generate as many support calls as resetting passwords, but lets not make those
people's lives miserable by introducing effects that they assumed not to exist
with the current minor version release. So please, just do all of us a favor and
do not backport it. Believe me, I know what I am talking about.
More information about the distro-pkg-dev