[rfc][icedtea-web] PolicyEditor gains a real parser

[Andrew Azores]

Hi,

I agree that the format is an odd one. It would be nice if the policies could instead use some other well-known format, although one (probably fairly minor) advantage of the existing policy file format over an XML format is simply that the current format is probably much more human-friendly when trying to read and evaluate the file manually, with a standard text editor. Nonetheless, dual support for the existing format as well as some other standardized format would be a very nice feature. Although not so much in the Java spirit as XML, and perhaps not as widely supported in the ecosystem, perhaps other formats to consider might include YAML or JSON, simply for their readability? What do you think of that?

Anyway, even once a format is selected, it will take some work to make this functional. It isn't just PolicyEditor and policytool that need to be "brought up to speed" with a new format, but also java.security.Policy at least, and other related classes. But I do like this idea and would like to explore further.

Thanks,

Andrew

----- Original Message -----
> On 12/26/2014 at 08:09 PM Andrew Azores wrote:
> > Hi all,
> > 
> > Long time no see!
> > 
> > I started this patch several months ago, but my school work became far
> > too heavy and I had to put off any further work to finish off this
> > patch. Today I've managed to finish it to a point that I think it's
> > worth submitting for review.
> > 
> > It's a big, long patch, so review will probably take quite some time,
> > and may be difficult at times. I know I've appeared to be completely
> > gone for many weeks, but I have actually been checking on my emails
> > fairly often, just haven't had time to reply to any patch reviews. But
> > right now I should have at least a few weeks before school really picks
> > back up again.
> > 
> > The gist of this patch is basically that I discovered that policytool's
> > parser is actually available to use without any dirty reflection hacks
> > or anything like that, but it's hidden away and not really documented,
> > and is marked as an internal API. But it's open and so I think the worst
> > case scenario if it's removed later is that we just fork and maintain an
> > older copy. It's much easier and IMHO smarter than writing a whole new
> > parser from scratch to duplicate the one that policytool uses, anyhow.
> > This patch just rips out the old, crappy code that used horrible regex
> > to try to parse policy files, and plops in the policytool parser
> > instead. Anything else pretty much comes down to reconciling the
> > existing PolicyEditor code and structures with the new ones that the
> > parser gives and expects.
> > 
> > Nice side effect: all policyeditor tests now pass, even the tricky
> > comments handling ones ;)
> 
> Although I have not reviewed the patch, I have to admit it is a good idea for
> PolicyEditor and policytool to share the same configuration file and Format
> (and parser code).
> However, I have always found policytool's file format very odd and doll to
> parse. In some sense it is quite "proprietary", except for conforming to
> ASCII.
> So, even though it is simple text it is not based on any other standard like
> SGML or XML. It is not even based on Java's "all-purpose" properties file
> format. I do not know if there is any need for this or how many people may be
> affected, but would you like to give it some thought developing a XML (with
> schema) or properties file format for policytool's and PolcyEditor's purpose?
> This new file format and parser could be added as an extension to policytool
> and PolicyEditor in the future. There is no need to drop support for
> policytool's current file format, but there certainly is still room for
> improvement. What do you think?
> 
> Jacob
>