[wildfly-dev] Proposing capabiities at completion time

Harald Pehl hpehl at redhat.com
Mon Sep 19 02:02:47 EDT 2016 

On Fri, Sep 16, 2016 at 7:56 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Re: only needing to use the static-name variant: Great!
>
> Re: the map, I’ll leave that to Harald or Claudio to answer. You made a
> solid point why it might not be necessary. I could imagine uses for the
> data (e.g. to let the user navigate to the related part of the UI) but I
> don’t know if those are real.
>

I agree that it's not necessary. My motivation was to give the user as much
information as possible. Though I see your point - and it might become
unnecessary complex to choose from a big list with lots of 'http' socket
bindings, when in the end it doesn't matter what entry was chosen.

So I'm ok with returning just a flat map.


>
> From the server side point of view I don’t think it would be particularly
> challenging to provide the map if it’s useful. From an API design point of
> view, an advantage of returning a more complex structure is if designed
> well initialiy it can be enhanced in the future to add more things that are
> wanted. The downside is a bigger payload than is needed for the simple use
> case.
>
> > On Sep 16, 2016, at 7:59 AM, Jean-Francois Denise <jdenise at redhat.com>
> wrote:
> >
> > Brian, my replies inlined. You will notice the question I am also asking
> about the need to return a Map.
> >
> >
> > On 16/09/16 14:53, Brian Stansberry wrote:
> >>> On Sep 16, 2016, at 3:50 AM, Jean-Francois Denise <jdenise at redhat.com>
> wrote:
> >>>
> >>> My reply inlined.
> >>>
> >>> On 15/09/16 21:15, Brian Stansberry wrote:
> >>>>> On Sep 15, 2016, at 2:05 PM, Harald Pehl <hpehl at redhat.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
> >>>>> I’m adding wildfly-dev in cc.
> >>>>>
> >>>>> Yes, the names of the parameters are ambiguous. And it’s not
> necessary for them to be ambiguous, as the “alternatives”, “required” and
> “requires" stuff lets us use clearly named params for different cases:
> >>>>>
> >>>>> “attribute” — required=true, alternatives=[parameter]
> >>>>> “parameter - required=true, alternatives=[attribute],
> requires=[operation]
> >>>>> “operation” - required=false
> >>>>>
> >>>>> An alternative is we could just drop all of those. The operation and
> attribute params are not necessary if the client has already done a
> read-resource-description or read-operation-description and already knows
> the value of the “capability-reference” descriptor. Then it could simply be
> >>>>>
> >>>>> /core-service=capability-registry:suggest-capabilities(
> address=[(subsystem=foo),(child=bar)],static-name=org.
> wildfly.network.socket-binding)
> >>>>> {
> >>>>>     “outcome” => “success”,
> >>>>>     “result” => [
> >>>>>         “http”,
> >>>>>         “https”
> >>>>>      ]
> >>>>> }
> >>>>>
> >>>>> From the console's perspective that version would work best for us.
> >>>>>
> >>>> Ok thanks.
> >>>>
> >>>> And both variants are possible if Jeff wants the other one for the
> CLI. The 'static-name' param could just be an alternative to ‘attribute’
> and ‘parameter’+’operation'.
> >>> I am not sure about the right syntax, We are possibly in the same case
> as HAL. If we offer a proper completion for the :write-attribute name
> (there is a start for this), we will have already accessed to the
> value-type and metadata for the deepest property. So we should have the
> capability-reference and call the operation with the couple Resource
> Address,Reference.
> >> How about other operations?
> > We are also navigating the value-type for low level operation arguments.
> So we have the static name too.
> >
>
> Ok, nice!
>
> >>
> >> The nice thing is if we just need static-name we can do that, and then
> if later we find we need more it can be added in a compatible way.
> >>
> >>>>> However I see one issue using this approach: If there are multiple
> suggestions having the same name while referring to different resources.
> This typically happens with attributes which have a capability reference to
> "org.wildfly.network.socket-binding" (for instance attribute
> "socket-binding" in "/subsystem=remoting/connector=*").
> >>>>>
> >>>>> Using /core-service=capability-registry:get-provider-points(
> name=org.wildfly.network.socket-binding) returns "/socket-binding-group=*/socket-binding=*"
> which resolves to several "http" socket-bindings in different
> socket-binding-groups.
> >>>>>
> >>>>> Just using the names as suggestions would end up in several "http"
> suggestions. What we do in that case in the console is to show some context:
> >>>>>
> >>>>> standard-sockets / http
> >>>>> ha-sockets / http
> >>>>> full-sockets / http
> >>>>> …
> >>>> To account for this instead of returning a simple list we can return
> an object node equivalent to a Map<String, Set<PathAddress>>.
> > *** Question on the advantage of having a map?
> >>> What is the advantage to expose all possible http capabilities? At the
> end the attribute value will only contain 'http' right? So do we really
> need to expose all the possibilities although whatever the user choice,
> 'http' will be stored in the value? For a given resource attribute value
> (eg: 'http') the server should be able to compute scopes and identify the
> right path (one of the 3 possible paths to 'http’).
> > ***
> >
> >>>>>  When thinking about this we should remember the dot/bracket syntax
> we allow for updating details of complex attributes via write-attribute:
> >>>>>
> >>>>> :write-attribute(name=complex.nested[2].field,value=http)
> >>>>>
> >>>>> For the CLI, just passing through “attribute”=>"complex.nested[2].field”
> is easier as there is no need for it to unpack the ‘.’ and ‘[]' syntax and
> find the description of ‘field’ and get the capabiity-reference.
> >>>>>
> >>>>> For the console, it may be easier to get the capability-reference
> and pass it instead. Easier than going from some code backing a gui widget
> and synthesizing "complex.nested[2].field” to pass to the server.
> >>>>>
> >>>>>
> >>>>>> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise <
> jdenise at redhat.com> wrote:
> >>>>>>
> >>>>>> The operation argument is an optional argument that contains the
> resource operation name. In case the operation is present, the attribute
> argument means operation argument. Otherwise the attribute contains the
> name of an attribute. This is a draft of operation, the operation naming
> could be reviewed.
> >>>>>> I don't think that this operation updates the capabilities
> registry, this is a readonly operation to retrieve capabilities.
> >>>>>> JF
> >>>>>>
> >>>>>> On 15/09/16 12:41, Harald Pehl wrote:
> >>>>>>> That looks very promising. Having such an operation would also
> cover the requirements of HAL. What's behind the "operation" parameter?
> Does it allow add / modify?
> >>>>>>>
> >>>>>>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise <
> jdenise at redhat.com> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> I have spent some time looking at the semantic of the capability
> scopes (thanks to Brian help).
> >>>>>>> A client "could" try to base its capability resolution by looking
> at capabilities present in the capabilities registry. Scope can be very
> complex, are possibly not fully modeled yet, and semantic could evolve in
> the future. So difficult for a client to rely on scopes to
> resolve the accessible capabilities.
> >>>>>>>
> >>>>>>> The server side has the logic to check the capabilities and could
> expose part of its engine logic to clients for capabilities resolution.
> Brian is proposing that the capabilities registry would expose a new
> operation:
> >>>>>>> /core-service=capability-registry:suggest-capabilities(
> address=[(subsystem=foo),(child=bar)],operation=add,
> >>>>>>> attribute=socket-binding)
> >>>>>>> {
> >>>>>>>     “outcome” => “success”,
> >>>>>>>     “result” => [
> >>>>>>>         “http”,
> >>>>>>>         “https”
> >>>>>>>      ]
> >>>>>>> }
> >>>>>>>
> >>>>>>> It seems that the CLI "completion requirements" would be covered
> by this addition. I am wandering if it would also cover the HAL ones?
> >>>>>>>
> >>>>>>> Thanks.
> >>>>>>>
> >>>>>>> JF
> >>>>>>>
> >>>>>>>
> >>>>>>> On 13/09/16 21:50, Harald Pehl wrote:
> >>>>>>>> See my answers inline.
> >>>>>>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise <
> jdenise at redhat.com> wrote:
> >>>>>>>> Hi Claudio and Harald, thank you for your reply. Some questions
> in-lined. I am just discovering the capabilities topic ;-) On 12/09/16
> 19:47, Claudio Miranda wrote:
> >>>>>>>> Your suggested approach looks similar to the way HAL does,
> however there are some differences. 1) There are many attributes that
> doesn't declare the capability-reference, (example: subsystem=transactions,
> attribute jdbc-store-datasource), then we emulate it.
> >>>>>>>> How do you emulate this? You are hard coding the list of
> attributes that are reference to capabilities? You can point me to some
> code? Harald, what is the technical difficulty there? Are they real
> capabilities? If the referenced resource can't register capabilities, are
> they actual capabilities?
> >>>>>>>> We have an internal registry [1] which is basically a map with
> the capability name as key and a class holding information about the
> capability as value [2]. Most entries in our registry are taken from
> /core-service=capability-registry, but to provide the capabilities also
> for WildFly < 11, we need to manually add entries to our registry during
> startup [3].
> >>>>>>>>
> >>>>>>>> 2) The capabilities and addresses are associated at bootstrap,
> this way HAL associates all capability-reference names to the target
> address it should lookup on at runtime. https://github.com/hal/core/blob/
> 26bb90653f60cfad2f3c3aac5964c4f125e18777/gui/src/main/java/
> org/jboss/as/console/client/meta/CoreCapabilitiesRegister.java
> >>>>>>>> This is the information that the capabilities registry contains?
> Right? I should be able to retrieve all that from the registry?
> >>>>>>>> Yes we read everything from /core-service=capability-registry
> >>>>>>>> 3) For domain mode, the attributes that declares capabilities
> resources out of profile, as socket-bindings, there is a small
> inconvenient, we need to display the full resource address, as there is no
> way to associate the profile to the socket-binding, we need to show all
> socket-binding of all socket-binding-groups, see
> http://i.imgur.com/86VP1F9.png
> >>>>>>>> The /<profile>/subsystem=transactions/process-id-socket-binding
> should be tagged with "capability-reference". Right? And it doesn't seem to
> be. Do you now the rational?
> >>>>>>>> Right, the r-r-d result for  /<profile>/subsystem=transactions
> does not contain a "capabilities-reference" for the attribute
> "process-id-socket-binding". This seems to be a bug in the transactions
> subsystem. But actually it's a good example how we can still provide
> typeahead support for attributes which do not have a "capability-reference"
> info [4]. This does not involve the capabilities registry. It's just about
> adding typeahead support for attributes which reference some other
> resources, but do not yet have a "capabilities-reference"
> >>>>>>>> Once the user has chosen a value, what are you setting as the
> value for the process-id-socket-binding attribute? Harald, you are saying
> that the resource name is taken as form input. So it means that only the
> last part of the resource address is stored? For example only "ajp"? Is it
> enough to fully identify the actual resource? Don't you need (full
> capabilities name + scope)?
> >>>>>>>> Yes that's right, only the resource name is stored. Let's take
> the server-group resource as an example. It has the attribute "profile"
> which declares the "capability-reference" "org.wildfly.domain.profile".
> When adding the resource, only the profile name is stored. AIUI to identify
> / verify the profile the attribute value and the information from the
> capabilities-regisrty are used.
> >>>>>>>>
> >>>>>>>> Thank-you.
> >>>>>>>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/
> main/java/org/jboss/hal/meta/capabilitiy/Capabilities.java
> >>>>>>>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/
> main/java/org/jboss/hal/meta/capabilitiy/Capability.java
> >>>>>>>> [3] https://github.com/hal/hal.next/blob/develop/app/src/
> main/java/org/jboss/hal/client/bootstrap/functions/
> ReadCapabilities.java#L65
> >>>>>>>> [4] https://github.com/hal/hal.next/blob/develop/app/src/
> main/resources/org/jboss/hal/client/configuration/subsystem/transactions/
> TransactionView.mbui.xml#L47
> >>>>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info
> >>>>>>> --
> >>>>>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info
> >>>>> --
> >>>>> Brian Stansberry
> >>>>> Manager, Senior Principal Software Engineer
> >>>>> JBoss by Red Hat
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ---
> >>>>> Harald Pehl
> >>>>> JBoss by Red Hat
> >>>>> http://hpehl.info
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>


-- 
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160919/ec1ddb74/attachment-0001.html

More information about the wildfly-dev mailing list