[rfc][icedtea-web] Preparing PolicyEditor for future full policyfile featureset

[Andrew Azores]

On 11/07/2014 09:12 AM, Jiri Vanek wrote:
> On 11/03/2014 07:41 PM, Andrew Azores wrote:
>> Hi,
>>
>> PolicyEditor is currently not a viable total replacement for the
>> existing JDK policytool for a few
>> reasons.
>
> Form quick look to code, changeset looks ok, but I'm quite wondering
> aout final goal. ...
>>
>> 1) Only supports CodeBase, not SignedBy and Principal
>> 2) No KeyStore entry support
>> 3) Parser is not a real parser
>> 4) CustomPolicyViewer is a little underpowered
>>
>> Once these issues are all resolved, then I think it would be fair for
>> us to push using PolicyEditor
>> alone, and remove the button from itweb-settings which launches
>> policytool as the "Advanced editor".
>
> And - do we wont to do so? Yes, maybe policy tool will be removed, then
> we will be forced.  But still - is good idea to rape this beautifully
> simple app - especially when used from "tmp permissions" button.
>>
>> This patch is aimed at working on #1 and #2. It adds a few more simple
>> data structures (KeystoreInfo
>> and PolicyIdentifier) so that, once a proper parser exists, a
>> full-featured policy file can be fully
>> modelled with PolicyEditor's structures. KeystoreInfo is currently
>> completely unused, and
>> PolicyIdentifier is used only for its codebase attribute, so there are
>> no behavioural changes after
>> this patch is applied. All unit tests should come up with the same
>> results (and the only unit test
>> changes made are refactoring for builder pattern) and manual testing
>> should work exactly the same as
>> well.
>>
>> Since PolicyEntries now have many more attributes, its constructor has
>> been made private and
>> PolicyEntry is now constructed with a Builder. Changing each of the
>> existing unit test cases dealing
>> with PolicyEntry to use the builder introduced some unfortunate noise
>> to this patch.
>>
>> Missing with this changeset are any changes to PolicyFileModel so that
>> these new attributes might be
>> written to file if (somehow) present. Since there is no UI to modify
>> these attributes and no parser
>> to read them from files, for now it will have to be done simply with
>> mock data and performed only in
>> unit tests. I'd like to add this as a separate changeset simply
>> because of the limited and highly
>> variable amounts of time I have to commit to this at the moment.
>>
>
> On contrary - there always was an question - what policyeditor do when
> it finds one of many unsupported parts of policy files. The only
> solution is what you suggest - to support them. But Any full supporting
> will lead to nasty PociyTool_II :(
>
> So before actually doing any code change, i would probably like to
> discuse final usecases, final gui, and final reactions to some cases.
>
> Some advance mode? Blah :( <me to stupid even for gui design> :(
> Completely reworked gui to support "everything" in really simple way?
> Some jtree with checkboxes and popupmenus? Maybe levels of advancenes?
> I'mnot sure if such editor is in scope of ITW.
>
>
> J.
>

Fair enough. I'd still like for PolicyEditor to be able to support these 
policy file features in the back end at least. Even if the GUI it 
exposes doesn't have any controls to view or modify these things, it 
feels broken to make a tool for editing policy files and have it 
actually be able to handle only some (arbitrary) subset of policy file 
syntax.

policytool also still frankly isn't very nice to use, and I think after 
giving PolicyEditor a nice back end with full policy file support, it 
wouldn't be *too* much work to create another front end on top of it to 
replace policytool, although this also would be made easier if more work 
is put in to refactoring what we have now into proper MVC (which I'm 
also willing to work on, slowly). Having both PolicyEditor and 
policytool2, both using the same back end, sounds pretty nice to me... 
maybe policytool2 and the back end could even be upstreamed and the 
nice, simple PolicyEditor GUI kept local to ITW, one day.

Thanks,
-- 
Andrew Azores