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

[Andrew Azores]

On 01/05/2015 03:59 PM, Jacob Wisor wrote:
> 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

Well, after some more consideration, I have no more argument here. XML 
does seem like the better choice of all the options examined, and I 
haven't come up with anything "better". The only downside anyway is, 
IMO, the not-so-human-readable nature of XML, but it isn't *that* bad 
anyway if it's reasonably formatted.

Thanks,
-- 
Andrew Azores