On Fri, Sep 16, 2016 at 7:56 PM, Brian Stansberry <
brian.stansberry(a)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(a)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(a)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(a)redhat.com>
wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 15, 2016 at 2:21 PM, Brian Stansberry <
brian.stansberry(a)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(a)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(a)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(a)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