[rfc][icedtea-web] policytool in itweb-settings

[Andrew Azores]

On 01/21/2014 12:29 PM, Jacob Wisor wrote:
> 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
>>>>>>>> compelxiity.
>>>>>>> [...]
>>>>>>>> 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
>>>>>>> backport
>>>>>>> DirectoryValidator? Or just let the 1.4 backport have less of a 
>>>>>>> guarantee
>>>>>>> that
>>>>>>> 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
>>>>>> creation.
>>>>>
>>>>> :-o Nooooo, please do not backport this! It is actually a new 
>>>>> feature, so it
>>>>> should rather go into the next minor version release.
>>>>>
>>>>> Jacob
>>>>>
>>>>
>>>> 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.
>>>
>>> Jacob
>>
>> 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.
>
> Jacob

Well, I see what you mean. I don't really see it causing problems but 
"better safe than sorry" I suppose.

Jiri, do you have a compelling argument against Jacob's? ;)

Thanks,

-- 
Andrew A