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

[Jacob Wisor]

On 01/01/2015 at 07:13 PM Andrew Azores wrote:
> 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?

AFAIK YAML has not been standardized, although it is colloquially called a
superset of JSON. JSON is good but its main purpose and strength lies in
converting or /serializing/ run-time *objects* into human-readable text for
*transmission*. Transmission is not actually key here. policytool and
PolicyEditor are storing *static* configuration *data* which may be subject to
parsing by external tools and/or need to be easily readable by human beings.
Static data calls for a document format. And, this is exactly what XML has been
originally designed for: documents. Unfortunatelly, many people and even
software architects did not get this point or have forgotten about it. Instead,
they just jumped onto a buzz word which indeed could or can offer stuctured,
human-readable, interoperable and standardized data, but you have to design
your XML schema for it. Just because XML may - when designing XML schmas
correctly - be human-readable too, it does not mean that it should be used for
every use-case which should require human-readability at some point in the
future. The main reason for XML loosing momentum and gaining somewhat negative
sentiments among developers especially during the last few years is because XML
has been abusively repurposed by many people. Sometimes not so much by technical
people but by management people who requested to have their products XML built
in, no matter the cost or merrit. There was a time where every commercial product
of significance or that wanted to become significant had to /speak/ XML. I am
just telling this in order to help you clear any confusing thoughts or things
you may have heard about how bad XML might be.

Anyway, I would advise not to use JSON for the purpose of policytool and
PolicyEditor and go for XML. Another important feature of XML as a static data
document format is that it convays implcit semantics. JSON does not do that.
JSON simply transmits data without neccessarily implying semantics. And
finally, XML documents can or should be defined by a schema. Schemas are great
because they help to validate XML documents as well as describe the semantics
of data. Again, afaik JSON does not offer anything similar except for simple
syntax checking. You cannot write a correct JSON object from scratch just by
looking at a batch of JSON objects and comparing them. However, you can do this
with XML documents, even more so when you have a schema at hand.

> 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.

Yep, it is definitely going to require some significant amount of work but I
think it could be worth it. Thank you for at least considering it and putting
some thought into it. :-)

Jacob

> ----- 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