[Pki-devel] CLI for editing profiles

[Fraser Tweedale]

On Wed, Sep 03, 2014 at 10:36:21AM -0500, Endi Sukma Dewata wrote:
> On 9/3/2014 12:25 AM, Fraser Tweedale wrote:
> >>>SimpleProperties and PropConfigStore currently live in
> >>>com.netscape.cmscore.base.  Is there any objection to moving them to
> >>>com.netscape.certsrv.base so that they are available to the CLI
> >>>code?
> >>>
> >>>This item is the last of the review items (including Endi's
> >>>subsequent review) blocking the next cut of the patchset.
> >>
> >>Do those classes have dependencies on other server-side classes? I was
> >>thinking to simply use java.util.Properties. Or maybe just a String then the
> >>ProfileClient parses it into a Properties.
> >>
> >Aha, I was not aware of java.util.Properties.  My immediate use case
> >doesn't require use of the sub-configs, so Properties would suffice.
> >Due to the heirarchical nature of profile config I suspect we might
> >*eventually* want PropConfigStore, but YAGNI for now, I guess.
> >
> >In regards to moving SimpleProperties and PropConfigStore, there is
> >one other class - SourceConfigStore - that would have to have been
> >moved.  AFAICT there are no other dependencies.
> >
> >On the subject of SimpleProperties: how does our SimpleProperties
> >class differ from java.util.Properties?  A cursory examination
> >reveals only two differences: SimpleProperties' hashCode() and
> >equals() methods take the `defaults' into account, whereas
> >Properties inherits this methods from java.util.HashTable.
> >
> >The only place SimpleProperties is used is in SourceConfigStore
> >(which extends it), and the only place SourceConfigStore is used is
> >in PropConfigStore (protected SourceConfigStore mSource).  Neither
> >PropConfigStore nor its subclasses invoke mSource.equals() or
> >.hashCode() so it seems - from this brief examination and without
> >the knowledge of history - that we could possibly get rid of
> >SimpleProperties?
> >
> >If there is an important reason why SimpleProperties exists, I look
> >forward to learning about it :)
> 
> I don't know the history either, but the SimpleProperties allows you to
> specify the default values of some properties so what you get is the
> effective values. This might be useful for the server because the server
> works using the effective property values, but I'm not sure if the current
> code is actually using it. On the client side we should be dealing with the
> configured properties only.
> 
> There are probably some other differences such as adding a header on the top
> of the file and the property value encoding. I don't think we need it on the
> client side though. Also note that some of these codes are quite old, and
> newer/better utility classes might have been added into the standard/common
> Java libraries since then, so in some cases it might be better to replace it
> if possible. Usually the hard part is testing it to make sure we're not
> breaking the existing functionality.
> 

`Properties' has both default values and header comments, FWIW.
Anyhow I'll leave the refactor for now and file a ticket, and
proceed with Properties for the client-side.

> -- 
> Endi S. Dewata