<div dir="ltr">We often derive the navigation in HAL from the management model tree. But it's also quite common that we shuffle things around and add own hierarchies to group resources differently. So I don't think that changing the hierarchy would make any difference in terms of HAL. <div><br></div><div>More important to me is a logical grouping of resources which belong together. This should be reflected in both the documentation and in HAL. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 28, 2016 at 1:23 PM, Darran Lofthouse <span dir="ltr"><<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Brian.<br>
<br>
I kind of think, even if we don't know the solution today but we do<br>
think usability is something we should handle in the admin tools then it<br>
will be better to leave the hierarchy as-is - alternatively if we felt<br>
this is insufficient information from the subsystem then modify the<br>
hierarchy there.<br>
<br>
In the documentation I want to add a structure similar to the grouping<br>
Claudio is using for HAL but generally if an administrator is looking to<br>
add a resource for a specific capability e.g. security-realm all<br>
resources will be listed together in the documentation.<br>
<br>
Another random CLI option: -<br>
<br>
Add an add-capability command relative to a point in the hierarchy.<br>
- capability would be a parameter which can tab complete based on<br>
capabilities at that point.<br>
- type can tab complete a much shorter list once we know the desired<br>
capability.<br>
- name the name the new resource will have.<br>
<br>
At that point additional parameters could tab complete as we know the<br>
resource type.<br>
<span class="HOEnZb"><font color="#888888"><br>
Darran.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 27/09/16 16:59, Brian Stansberry wrote:<br>
><br>
>> On Sep 27, 2016, at 9:47 AM, Darran Lofthouse <<a href="mailto:darran.lofthouse@jboss.com">darran.lofthouse@jboss.com</a>> wrote:<br>
>><br>
>> I have received the following request regarding the hierarchy of the<br>
>> Elytron subystem so just wanted to get some additional opinions: -<br>
>><br>
>> <a href="https://issues.jboss.org/browse/WFLY-7190" rel="noreferrer" target="_blank">https://issues.jboss.org/<wbr>browse/WFLY-7190</a><br>
>><br>
>> The Elytron subsystem is implemented by having a number of different<br>
>> capabilities that are then chained together in the model to expose four<br>
>> / five capabilities that are then used across the application server to<br>
>> access security related services.<br>
>><br>
>> <a href="https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/elytron_integration/org/wildfly/security" rel="noreferrer" target="_blank">https://github.com/wildfly-<wbr>security-incubator/wildfly-<wbr>capabilities/tree/elytron_<wbr>integration/org/wildfly/<wbr>security</a><br>
>><br>
>> The reason for following the capability approach along with a component<br>
>> assembly approach to assembling the configuration is so that we are<br>
>> ready for other subsystems to be added to the server potentially<br>
>> providing their own implementations of these capabilities.<br>
>><br>
>> For our capabilities we have one or more resource definitions making it<br>
>> possible to configure different implementations of the capabilities<br>
>> whilst having the configuration fully described in the model unlike the<br>
>> previous map approach for login modules.<br>
>><br>
>> So the general problem is how should an administrator be able to see the<br>
>> resources by type.<br>
>><br>
>> Within the admin console Claudio it looking at a tabbed interface where<br>
>> different tabs can contain different resources so that seems to be<br>
>> reasonably covered.<br>
>><br>
>> Within the CLI however an administrator is just presented by all<br>
>> resource types within the subsystem when they use tab completion.<br>
>><br>
>> One option could be for us to introduce an arbitrary layer in the<br>
>> subsystem and group our resources, e.g.<br>
>><br>
>> /subsystem=elytron/component=<wbr>name-rewriter/<br>
>> /subsystem=elytron/component=<wbr>security-realm/<br>
>><br>
><br>
> So then<br>
><br>
> /subsystem=elytron/component=<wbr>name-rewriter/custom-name-<wbr>rewriter=foo<br>
> /subsystem=elytron/component=<wbr>security-realm/jdbc-realm=bar<br>
><br>
> That’s not clearly a benefit; it may be worse.<br>
><br>
> The point here is better navigation. So the user isn’t sure:<br>
><br>
> /subsystem=elytron/<TAB><br>
><br>
> Now unless there are no normal children, you see whatever stuff remains at the top, and ‘component’. Picking a couple at random to provide an example<br>
><br>
> component dir-context empty-role-decoder ...<br>
><br>
> Now ‘component’ isn’t intuitive at all. But if the list is only 3-4 or less then maybe they guess it. Otherwise it is both obscure and buried amongst other things.<br>
><br>
> /subsystem=elytron/component=<<wbr>TAB><br>
><br>
> Now they get a more refined list, and there is some benefit<br>
><br>
> name-writer security-realm …<br>
><br>
> /subsystem=elytron/component=<wbr>name-rewriter/<TAB><br>
><br>
> custom-name-rewriter constant-name-rewriter …..<br>
><br>
> And finally they get to<br>
><br>
> /subsystem=elytron/component=<wbr>name-rewriter/custom-name-<wbr>rewriter<br>
><br>
> That’s 2 extra tab completes (four if you count the extra ‘=‘ and ‘/‘ in the path), the decision that ‘component’ is what they want, and the recognition that the thing they want, a ‘custom-name-rewriter’ is a form of ‘name-rewriter’.<br>
><br>
> So it’s dubious there is much of a gain. And of course for other use cases where people know what they want it’s added superfluous typing.<br>
><br>
> A side benefit of the added level is it provides a place to describe the general characteristics of the component category in the read-resource-description output.<br>
><br>
>> But before taking that approach it feels as though this information is<br>
>> already there and there are possibly some other alternatives we could<br>
>> consider.<br>
>><br>
>> Firstly I wonder if some of the read-* operations could have an<br>
>> opportunity to take into account capabilities of child resources to<br>
>> offer a filtered view?<br>
>><br>
><br>
> So<br>
><br>
> /subsystem=elytron:read-<wbr>children-types(provided-<wbr>capability=org.wildfly.<wbr>elytron.name-rewriter)<br>
><br>
> I’m not sure how much that helps. This call would be used by the CLI to feed tab completion, not the user. But somehow the CLI needs the value 'org.wildfly.elytron.name-<wbr>rewriter’ and that cannot be inferred; it requires user input.<br>
><br>
> Or<br>
><br>
> /subsystem=elytron:read-<wbr>children-resources(provided-<wbr>capability=org.wildfly.<wbr>elytron.name-rewriter)<br>
><br>
> Here there’s some benefit but CLI would need to offer tab completion for 'provided-capability’.<br>
><br>
> Before I’d want to invest energy in implementing that I’d like to see some concrete demand for that exact use case. It’s a pretty big jump from ‘the subsystem is too flat’ to “significant numbers of users will make use of this specific read-children-resources variant"<br>
><br>
>> Another possible option could be CLI commands e.g. add-name-rewriter,<br>
>> add-security-realm - not sure if that would be one way to give a better<br>
>> user experience.<br>
>><br>
><br>
> This seems more direct. TBH though I’ve spent most of my thinking on my bits above and haven’t thought hard about this one. :)<br>
><br>
>> Anyway just some random thoughts for the moment but wanted to open this<br>
>> up before jumping immediately to the artificial hierarchy solution.<br>
>><br>
>> Regards,<br>
>> Darran Lofthouse.<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> wildfly-dev mailing list<br>
>> <a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br>
><br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">
---<br>Harald Pehl<br>JBoss by Red Hat<br><a href="http://hpehl.info" target="_blank">http://hpehl.info</a></div></div>
</div>