Re: [Pki-devel] CLI for editing profiles
On Tue, Sep 02, 2014 at 11:38:42PM -0500, Endi Sukma Dewata wrote:
On 9/2/2014 9:16 PM, Fraser Tweedale wrote:
>>>>13. The ProfileResource.retrieveProfileRaw() returns a byte[]. Although
it
>>>>works just fine for this purpose, I think returning a Properties would
make
>>>>it more developer-friendly. That way the output is readily usable, and
it
>>>>takes care of any CR/LF issue across different platforms. Maybe call it
>>>>getProfileProperties()?
>>>>
>>>I'll look into this implications and benefits of doing this... once
>>>I've done all the other things :)
>>>
>>+1 Lets make it more developer friendly.
>>
>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 :)
Regards,
Fraser
--
Endi S. Dewata