Capability naming conventions

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Capability naming conventions

Brian Stansberry
The capability and requirement stuff[1] is far enough along that real
usage is happening, so actual capability names are being created.[2] I
wanted to get some input regarding naming conventions for capability
names so it doesn't devovle into chaos, and so I don't end up making up
a lot of names people hate.

The key thing is capabilities need to be namespaced to avoid collisions
between capability creators. Beyond that the names should be "good",
whatever that means (user friendly, properly targeted, not overly tied
to implementation, etc).

My initial thinking on this was:

1) The WildFly family projects own the "org.wildfly" namespace. So all
capabilities we create fit in that namespace, and no one else puts
things there. This I think is a must.

2) Capabilities not used by or provided by the WildFly kernel go in
subspace org.wildfly.extension.<name_of_extension>. Idea there was just
to avoid naming collisions between different extensions.

I don't think 2) is such a great idea any more. A given capability be
provided by more than one extension, so there isn't a clean conceptual
mapping. And the word "extension" is really an implementation detail.

So, I'm inclined to drop the "extension" bit.

Any thoughts on this, or other aspects of how to name capabilities?

FYI, see [3] for some names of capabilities that will be used by the kernel.

[1] The "Runtime" aspect of https://developer.jboss.org/docs/DOC-52712
[2] https://github.com/wildfly/wildfly/pull/7596
[3] https://developer.jboss.org/docs/DOC-53383

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

David Lloyd-2
On 06/12/2015 03:22 PM, Brian Stansberry wrote:

> The capability and requirement stuff[1] is far enough along that real
> usage is happening, so actual capability names are being created.[2] I
> wanted to get some input regarding naming conventions for capability
> names so it doesn't devovle into chaos, and so I don't end up making up
> a lot of names people hate.
>
> The key thing is capabilities need to be namespaced to avoid collisions
> between capability creators. Beyond that the names should be "good",
> whatever that means (user friendly, properly targeted, not overly tied
> to implementation, etc).
>
> My initial thinking on this was:
>
> 1) The WildFly family projects own the "org.wildfly" namespace. So all
> capabilities we create fit in that namespace, and no one else puts
> things there. This I think is a must.
>
> 2) Capabilities not used by or provided by the WildFly kernel go in
> subspace org.wildfly.extension.<name_of_extension>. Idea there was just
> to avoid naming collisions between different extensions.
>
> I don't think 2) is such a great idea any more. A given capability be
> provided by more than one extension, so there isn't a clean conceptual
> mapping. And the word "extension" is really an implementation detail.
>
> So, I'm inclined to drop the "extension" bit.
>
> Any thoughts on this, or other aspects of how to name capabilities?

Sounds good to me.  I'd like to add that internally, we should make sure
we continue to maintain some registry of our org.wildfly name spaces
somewhere (maybe even just a git repository would be OK) so we don't
conflict among ourselves.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Anil Saldanha
Is there an inbuilt mechanism in the capabilities ecosystem that disallows system integrators from writing capabilities in the org.wildfly namespace? 
This is important lest it becomes a wild west in terms of capabilities. :-)

On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <[hidden email]> wrote:
On 06/12/2015 03:22 PM, Brian Stansberry wrote:
> The capability and requirement stuff[1] is far enough along that real
> usage is happening, so actual capability names are being created.[2] I
> wanted to get some input regarding naming conventions for capability
> names so it doesn't devovle into chaos, and so I don't end up making up
> a lot of names people hate.
>
> The key thing is capabilities need to be namespaced to avoid collisions
> between capability creators. Beyond that the names should be "good",
> whatever that means (user friendly, properly targeted, not overly tied
> to implementation, etc).
>
> My initial thinking on this was:
>
> 1) The WildFly family projects own the "org.wildfly" namespace. So all
> capabilities we create fit in that namespace, and no one else puts
> things there. This I think is a must.
>
> 2) Capabilities not used by or provided by the WildFly kernel go in
> subspace org.wildfly.extension.<name_of_extension>. Idea there was just
> to avoid naming collisions between different extensions.
>
> I don't think 2) is such a great idea any more. A given capability be
> provided by more than one extension, so there isn't a clean conceptual
> mapping. And the word "extension" is really an implementation detail.
>
> So, I'm inclined to drop the "extension" bit.
>
> Any thoughts on this, or other aspects of how to name capabilities?

Sounds good to me.  I'd like to add that internally, we should make sure
we continue to maintain some registry of our org.wildfly name spaces
somewhere (maybe even just a git repository would be OK) so we don't
conflict among ourselves.

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Brian Stansberry
In reply to this post by David Lloyd-2
On 6/12/15 4:24 PM, David M. Lloyd wrote:

>
> Sounds good to me.  I'd like to add that internally, we should make sure
> we continue to maintain some registry of our org.wildfly name spaces
> somewhere (maybe even just a git repository would be OK) so we don't
> conflict among ourselves.
>

Like a text file per capability, with some doc on the capability in the
file? Files organized in a tree from the names?

That sounds good; much better than some wiki.

--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Brian Stansberry
In reply to this post by Anil Saldanha
No, there isn't.

On 6/12/15 4:30 PM, Anil Saldhana wrote:

> Is there an inbuilt mechanism in the capabilities ecosystem that
> disallows system integrators from writing capabilities in the
> org.wildfly namespace?
> This is important lest it becomes a wild west in terms of capabilities. :-)
>
> On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
>     > The capability and requirement stuff[1] is far enough along that real
>     > usage is happening, so actual capability names are being created.[2] I
>     > wanted to get some input regarding naming conventions for capability
>     > names so it doesn't devovle into chaos, and so I don't end up making up
>     > a lot of names people hate.
>     >
>     > The key thing is capabilities need to be namespaced to avoid collisions
>     > between capability creators. Beyond that the names should be "good",
>     > whatever that means (user friendly, properly targeted, not overly tied
>     > to implementation, etc).
>     >
>     > My initial thinking on this was:
>     >
>     > 1) The WildFly family projects own the "org.wildfly" namespace. So all
>     > capabilities we create fit in that namespace, and no one else puts
>     > things there. This I think is a must.
>     >
>     > 2) Capabilities not used by or provided by the WildFly kernel go in
>     > subspace org.wildfly.extension.<name_of_extension>. Idea there was just
>     > to avoid naming collisions between different extensions.
>     >
>     > I don't think 2) is such a great idea any more. A given capability be
>     > provided by more than one extension, so there isn't a clean conceptual
>     > mapping. And the word "extension" is really an implementation detail.
>     >
>     > So, I'm inclined to drop the "extension" bit.
>     >
>     > Any thoughts on this, or other aspects of how to name capabilities?
>
>     Sounds good to me.  I'd like to add that internally, we should make sure
>     we continue to maintain some registry of our org.wildfly name spaces
>     somewhere (maybe even just a git repository would be OK) so we don't
>     conflict among ourselves.
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Anil Saldanha
It probably is not a big deal TBH.  A proper documented wiki with guidelines for capabilities is all you need. A capability namespace enforcement model (though a capability of its own) is an overkill.  I was just curious. ;)

May I suggest adding some diagrams on your capabilities wiki page explaining the key concepts behind it. I had to dig deep to understand the differences between capabilities and modules.

On Fri, Jun 12, 2015 at 4:34 PM, Brian Stansberry <[hidden email]> wrote:
No, there isn't.

On 6/12/15 4:30 PM, Anil Saldhana wrote:
> Is there an inbuilt mechanism in the capabilities ecosystem that
> disallows system integrators from writing capabilities in the
> org.wildfly namespace?
> This is important lest it becomes a wild west in terms of capabilities. :-)
>
> On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
>     > The capability and requirement stuff[1] is far enough along that real
>     > usage is happening, so actual capability names are being created.[2] I
>     > wanted to get some input regarding naming conventions for capability
>     > names so it doesn't devovle into chaos, and so I don't end up making up
>     > a lot of names people hate.
>     >
>     > The key thing is capabilities need to be namespaced to avoid collisions
>     > between capability creators. Beyond that the names should be "good",
>     > whatever that means (user friendly, properly targeted, not overly tied
>     > to implementation, etc).
>     >
>     > My initial thinking on this was:
>     >
>     > 1) The WildFly family projects own the "org.wildfly" namespace. So all
>     > capabilities we create fit in that namespace, and no one else puts
>     > things there. This I think is a must.
>     >
>     > 2) Capabilities not used by or provided by the WildFly kernel go in
>     > subspace org.wildfly.extension.<name_of_extension>. Idea there was just
>     > to avoid naming collisions between different extensions.
>     >
>     > I don't think 2) is such a great idea any more. A given capability be
>     > provided by more than one extension, so there isn't a clean conceptual
>     > mapping. And the word "extension" is really an implementation detail.
>     >
>     > So, I'm inclined to drop the "extension" bit.
>     >
>     > Any thoughts on this, or other aspects of how to name capabilities?
>
>     Sounds good to me.  I'd like to add that internally, we should make sure
>     we continue to maintain some registry of our org.wildfly name spaces
>     somewhere (maybe even just a git repository would be OK) so we don't
>     conflict among ourselves.
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Brian Stansberry
On 6/12/15 4:41 PM, Anil Saldhana wrote:
> It probably is not a big deal TBH.  A proper documented wiki with
> guidelines for capabilities is all you need. A capability namespace
> enforcement model (though a capability of its own) is an overkill.  I
> was just curious. ;)
>

Ok, good, as that wouldn't be trivial!

> May I suggest adding some diagrams on your capabilities wiki page
> explaining the key concepts behind it. I had to dig deep to understand
> the differences between capabilities and modules.
>

I want to add a section to the "Extending WildFly" docs[1]. This
distinction is a good one to clarify.

Perhaps I should call if a "managed capability" as this is all about
stuff that functionality via the WildFly Core management layer.

The distinction between an extension and a managed capability is another
good one.

[1] https://docs.jboss.org/author/display/WFLY9/Extending+WildFly

> On Fri, Jun 12, 2015 at 4:34 PM, Brian Stansberry
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     No, there isn't.
>
>     On 6/12/15 4:30 PM, Anil Saldhana wrote:
>     > Is there an inbuilt mechanism in the capabilities ecosystem that
>     > disallows system integrators from writing capabilities in the
>     > org.wildfly namespace?
>     > This is important lest it becomes a wild west in terms of capabilities. :-)
>     >
>     > On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <[hidden email] <mailto:[hidden email]>
>      > <mailto:[hidden email] <mailto:[hidden email]>>>
>     wrote:
>      >
>      >     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
>      >     > The capability and requirement stuff[1] is far enough along
>     that real
>      >     > usage is happening, so actual capability names are being
>     created.[2] I
>      >     > wanted to get some input regarding naming conventions for
>     capability
>      >     > names so it doesn't devovle into chaos, and so I don't end
>     up making up
>      >     > a lot of names people hate.
>      >     >
>      >     > The key thing is capabilities need to be namespaced to
>     avoid collisions
>      >     > between capability creators. Beyond that the names should
>     be "good",
>      >     > whatever that means (user friendly, properly targeted, not
>     overly tied
>      >     > to implementation, etc).
>      >     >
>      >     > My initial thinking on this was:
>      >     >
>      >     > 1) The WildFly family projects own the "org.wildfly"
>     namespace. So all
>      >     > capabilities we create fit in that namespace, and no one
>     else puts
>      >     > things there. This I think is a must.
>      >     >
>      >     > 2) Capabilities not used by or provided by the WildFly
>     kernel go in
>      >     > subspace org.wildfly.extension.<name_of_extension>. Idea
>     there was just
>      >     > to avoid naming collisions between different extensions.
>      >     >
>      >     > I don't think 2) is such a great idea any more. A given
>     capability be
>      >     > provided by more than one extension, so there isn't a clean
>     conceptual
>      >     > mapping. And the word "extension" is really an
>     implementation detail.
>      >     >
>      >     > So, I'm inclined to drop the "extension" bit.
>      >     >
>      >     > Any thoughts on this, or other aspects of how to name
>     capabilities?
>      >
>      >     Sounds good to me.  I'd like to add that internally, we
>     should make sure
>      >     we continue to maintain some registry of our org.wildfly name
>     spaces
>      >     somewhere (maybe even just a git repository would be OK) so
>     we don't
>      >     conflict among ourselves.
>      >
>      >     --
>      >     - DML
>      >     _______________________________________________
>      >     wildfly-dev mailing list
>      > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     >[hidden email] <mailto:[hidden email]>
>     >https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     >
>
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

kkhan
In reply to this post by Brian Stansberry

> On 12 Jun 2015, at 22:31, Brian Stansberry <[hidden email]> wrote:
>
> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>
>>
>> Sounds good to me.  I'd like to add that internally, we should make sure
>> we continue to maintain some registry of our org.wildfly name spaces
>> somewhere (maybe even just a git repository would be OK) so we don't
>> conflict among ourselves.
>>
>
> Like a text file per capability, with some doc on the capability in the
> file? Files organized in a tree from the names?
>
> That sounds good; much better than some wiki.
+1
I don’t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Brian Stansberry
On 6/13/15 4:00 AM, Kabir Khan wrote:

>
>> On 12 Jun 2015, at 22:31, Brian Stansberry <[hidden email]> wrote:
>>
>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>
>>>
>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>> we continue to maintain some registry of our org.wildfly name spaces
>>> somewhere (maybe even just a git repository would be OK) so we don't
>>> conflict among ourselves.
>>>
>>
>> Like a text file per capability, with some doc on the capability in the
>> file? Files organized in a tree from the names?
>>
>> That sounds good; much better than some wiki.
> +1
> I don’t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.

How about this?

https://github.com/bstansberry/wildfly-core/

The README.md explains things pretty clearly.

At this point it just has a couple capabilities; ones added in the PR at

https://github.com/wildfly/wildfly-core/pull/810

That repo has a LICENSE file, which specifies ASL 2.0. I don't know if
such a thing is really necessary, or if some other license, like
Creative Commons, is more appropriate.

>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Brian Stansberry
In reply to this post by kkhan
On 6/13/15 4:00 AM, Kabir Khan wrote:

>
>> On 12 Jun 2015, at 22:31, Brian Stansberry <[hidden email]> wrote:
>>
>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>
>>>
>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>> we continue to maintain some registry of our org.wildfly name spaces
>>> somewhere (maybe even just a git repository would be OK) so we don't
>>> conflict among ourselves.
>>>
>>
>> Like a text file per capability, with some doc on the capability in the
>> file? Files organized in a tree from the names?
>>
>> That sounds good; much better than some wiki.
> +1
> I don’t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.

How about this?

https://github.com/bstansberry/wildfly-capabilities

The README.md explains things pretty clearly.

At this point it just has the capabilities currentl in core, including
unmerged ones added in the PR at

https://github.com/wildfly/wildfly-core/pull/810

That repo has a LICENSE file, which specifies ASL 2.0. I don't know if
such a thing is really necessary, or if some other license, like
Creative Commons, is more appropriate.

>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Max Rydahl Andersen-2
Just one quick suggestion.

Instead of .txt, use .adoc then it will actually render nicely on github
out-of-box and you get access to
do tables and lists etc. in something that is readable as text and look
nice rendered.

/max

> On 6/13/15 4:00 AM, Kabir Khan wrote:
>>
>>> On 12 Jun 2015, at 22:31, Brian Stansberry
>>> <[hidden email]> wrote:
>>>
>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>
>>>>
>>>> Sounds good to me.  I'd like to add that internally, we should make
>>>> sure
>>>> we continue to maintain some registry of our org.wildfly name
>>>> spaces
>>>> somewhere (maybe even just a git repository would be OK) so we
>>>> don't
>>>> conflict among ourselves.
>>>>
>>>
>>> Like a text file per capability, with some doc on the capability in
>>> the
>>> file? Files organized in a tree from the names?
>>>
>>> That sounds good; much better than some wiki.
>> +1
>> I don’t know enough about this yet to suggest a format, but having
>> it somewhere in the source is a lot better than a wiki. A wiki brings
>> to mind that horrible log ids page we used for AS 7.
>
> How about this?
>
> https://github.com/bstansberry/wildfly-capabilities
>
> The README.md explains things pretty clearly.
>
> At this point it just has the capabilities currentl in core, including
> unmerged ones added in the PR at
>
> https://github.com/wildfly/wildfly-core/pull/810
>
> That repo has a LICENSE file, which specifies ASL 2.0. I don't know if
> such a thing is really necessary, or if some other license, like
> Creative Commons, is more appropriate.
>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Brian Stansberry
Thanks; that's a good idea.

On 6/19/15 8:18 AM, Max Rydahl Andersen wrote:

> Just one quick suggestion.
>
> Instead of .txt, use .adoc then it will actually render nicely on github
> out-of-box and you get access to
> do tables and lists etc. in something that is readable as text and look
> nice rendered.
>
> /max
>
>> On 6/13/15 4:00 AM, Kabir Khan wrote:
>>>
>>>> On 12 Jun 2015, at 22:31, Brian Stansberry
>>>> <[hidden email]> wrote:
>>>>
>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>>
>>>>>
>>>>> Sounds good to me.  I'd like to add that internally, we should make
>>>>> sure
>>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>>> conflict among ourselves.
>>>>>
>>>>
>>>> Like a text file per capability, with some doc on the capability in the
>>>> file? Files organized in a tree from the names?
>>>>
>>>> That sounds good; much better than some wiki.
>>> +1
>>> I don’t know enough about this yet to suggest a format, but having it
>>> somewhere in the source is a lot better than a wiki. A wiki brings to
>>> mind that horrible log ids page we used for AS 7.
>>
>> How about this?
>>
>> https://github.com/bstansberry/wildfly-capabilities
>>
>> The README.md explains things pretty clearly.
>>
>> At this point it just has the capabilities currentl in core, including
>> unmerged ones added in the PR at
>>
>> https://github.com/wildfly/wildfly-core/pull/810
>>
>> That repo has a LICENSE file, which specifies ASL 2.0. I don't know if
>> such a thing is really necessary, or if some other license, like
>> Creative Commons, is more appropriate.
>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> /max
> http://about.me/maxandersen


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Darran Lofthouse
In reply to this post by Anil Saldanha
On 12/06/15 22:30, Anil Saldhana wrote:
> Is there an inbuilt mechanism in the capabilities ecosystem that
> disallows system integrators from writing capabilities in the
> org.wildfly namespace?
> This is important lest it becomes a wild west in terms of capabilities. :-)

Actually it is desirable that system integrators do use the names we
define, if we define that a capability is provided under a specific name
the integrator can do two different things: -

  1 - Depend on a capability that we supply.
  2 - Provide their own implementation of that capability.

e.g. in the future I would love to see a situation where a third party
company specialising in security software could add their own subsystem
that provides the TrustManager capability to plug in their own trust
infrastructure.

> On Fri, Jun 12, 2015 at 4:24 PM, David M. Lloyd <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 06/12/2015 03:22 PM, Brian Stansberry wrote:
>     > The capability and requirement stuff[1] is far enough along that real
>     > usage is happening, so actual capability names are being created.[2] I
>     > wanted to get some input regarding naming conventions for capability
>     > names so it doesn't devovle into chaos, and so I don't end up making up
>     > a lot of names people hate.
>     >
>     > The key thing is capabilities need to be namespaced to avoid collisions
>     > between capability creators. Beyond that the names should be "good",
>     > whatever that means (user friendly, properly targeted, not overly tied
>     > to implementation, etc).
>     >
>     > My initial thinking on this was:
>     >
>     > 1) The WildFly family projects own the "org.wildfly" namespace. So all
>     > capabilities we create fit in that namespace, and no one else puts
>     > things there. This I think is a must.
>     >
>     > 2) Capabilities not used by or provided by the WildFly kernel go in
>     > subspace org.wildfly.extension.<name_of_extension>. Idea there was just
>     > to avoid naming collisions between different extensions.
>     >
>     > I don't think 2) is such a great idea any more. A given capability be
>     > provided by more than one extension, so there isn't a clean conceptual
>     > mapping. And the word "extension" is really an implementation detail.
>     >
>     > So, I'm inclined to drop the "extension" bit.
>     >
>     > Any thoughts on this, or other aspects of how to name capabilities?
>
>     Sounds good to me.  I'd like to add that internally, we should make sure
>     we continue to maintain some registry of our org.wildfly name spaces
>     somewhere (maybe even just a git repository would be OK) so we don't
>     conflict among ourselves.
>
>     --
>     - DML
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Darran Lofthouse
In reply to this post by kkhan
IMO if we add it to our source repo we should just add it to our source,
that would also provide a central point other subsystems can reference
it from.

Having a policy of put it in a text file in our source repo but don't
allow it in a shared class file seems wrong.

On 13/06/15 10:00, Kabir Khan wrote:

>
>> On 12 Jun 2015, at 22:31, Brian Stansberry <[hidden email]> wrote:
>>
>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>
>>>
>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>> we continue to maintain some registry of our org.wildfly name spaces
>>> somewhere (maybe even just a git repository would be OK) so we don't
>>> conflict among ourselves.
>>>
>>
>> Like a text file per capability, with some doc on the capability in the
>> file? Files organized in a tree from the names?
>>
>> That sounds good; much better than some wiki.
> +1
> I don’t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

David Lloyd-2
The problem is, that's not *really* central.  The version of
wildfly-core does not impact what namespaces exist or are recognized by
subsystems.  However, putting the registry in that repository means that
certain names, which are possibly not even referenced from wildfly-core,
become unavailable for no good reason.

On the other hand, having a separate registry encourages add-on packages
and other third parties to participate in registration without the
additional coordination overhead required in creating releases for the
change to become visible to the greater world.  This becomes even more
significant as we maintain multiple branches.

Finally, having external name registries is standard practice for plenty
of situations similar to this one (RFC implementations for example), for
all the reasons I've given above.

On 06/22/2015 06:54 AM, Darran Lofthouse wrote:

> IMO if we add it to our source repo we should just add it to our source,
> that would also provide a central point other subsystems can reference
> it from.
>
> Having a policy of put it in a text file in our source repo but don't
> allow it in a shared class file seems wrong.
>
> On 13/06/15 10:00, Kabir Khan wrote:
>>
>>> On 12 Jun 2015, at 22:31, Brian Stansberry <[hidden email]> wrote:
>>>
>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>
>>>>
>>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>> conflict among ourselves.
>>>>
>>>
>>> Like a text file per capability, with some doc on the capability in the
>>> file? Files organized in a tree from the names?
>>>
>>> That sounds good; much better than some wiki.
>> +1
>> I don’t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Darran Lofthouse
Do we have other naming conventions where we could make use of a central
registry?

Thinking about HTTP and SASL authentication mechanisms, these are
predominantly using IANA registered names but we do have a few exceptions.

If we ever want to be doing anything with custom LDAP schemas these can
require OID definitions.

We do also have a large number of XML schema namespaces although
probably not a good example as we have not experienced conflict here.


On 22/06/15 13:33, David M. Lloyd wrote:

> The problem is, that's not *really* central.  The version of
> wildfly-core does not impact what namespaces exist or are recognized by
> subsystems.  However, putting the registry in that repository means that
> certain names, which are possibly not even referenced from wildfly-core,
> become unavailable for no good reason.
>
> On the other hand, having a separate registry encourages add-on packages
> and other third parties to participate in registration without the
> additional coordination overhead required in creating releases for the
> change to become visible to the greater world.  This becomes even more
> significant as we maintain multiple branches.
>
> Finally, having external name registries is standard practice for plenty
> of situations similar to this one (RFC implementations for example), for
> all the reasons I've given above.
>
> On 06/22/2015 06:54 AM, Darran Lofthouse wrote:
>> IMO if we add it to our source repo we should just add it to our source,
>> that would also provide a central point other subsystems can reference
>> it from.
>>
>> Having a policy of put it in a text file in our source repo but don't
>> allow it in a shared class file seems wrong.
>>
>> On 13/06/15 10:00, Kabir Khan wrote:
>>>
>>>> On 12 Jun 2015, at 22:31, Brian Stansberry <[hidden email]> wrote:
>>>>
>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>>
>>>>>
>>>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>>> conflict among ourselves.
>>>>>
>>>>
>>>> Like a text file per capability, with some doc on the capability in the
>>>> file? Files organized in a tree from the names?
>>>>
>>>> That sounds good; much better than some wiki.
>>> +1
>>> I don’t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

David Lloyd-2
Yes, definitely.  I already maintain SLP identifiers and related hokum
in "RHANANA" which is AFAIK presently internal-only (but is also the
place where we should be maintaining OIDs and other IANA stuff), but
there are definitely at least a couple of other things that I believe
can/should be centralized outside of the code base; off the top of my head:

* Deployment descriptor schemas
* (Perhaps controversially) Resource names and descriptions incl. XML
schemas

On 06/22/2015 07:46 AM, Darran Lofthouse wrote:

> Do we have other naming conventions where we could make use of a central
> registry?
>
> Thinking about HTTP and SASL authentication mechanisms, these are
> predominantly using IANA registered names but we do have a few exceptions.
>
> If we ever want to be doing anything with custom LDAP schemas these can
> require OID definitions.
>
> We do also have a large number of XML schema namespaces although
> probably not a good example as we have not experienced conflict here.
>
>
> On 22/06/15 13:33, David M. Lloyd wrote:
>> The problem is, that's not *really* central.  The version of
>> wildfly-core does not impact what namespaces exist or are recognized by
>> subsystems.  However, putting the registry in that repository means that
>> certain names, which are possibly not even referenced from wildfly-core,
>> become unavailable for no good reason.
>>
>> On the other hand, having a separate registry encourages add-on packages
>> and other third parties to participate in registration without the
>> additional coordination overhead required in creating releases for the
>> change to become visible to the greater world.  This becomes even more
>> significant as we maintain multiple branches.
>>
>> Finally, having external name registries is standard practice for plenty
>> of situations similar to this one (RFC implementations for example), for
>> all the reasons I've given above.
>>
>> On 06/22/2015 06:54 AM, Darran Lofthouse wrote:
>>> IMO if we add it to our source repo we should just add it to our source,
>>> that would also provide a central point other subsystems can reference
>>> it from.
>>>
>>> Having a policy of put it in a text file in our source repo but don't
>>> allow it in a shared class file seems wrong.
>>>
>>> On 13/06/15 10:00, Kabir Khan wrote:
>>>>
>>>>> On 12 Jun 2015, at 22:31, Brian Stansberry <[hidden email]> wrote:
>>>>>
>>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>>>
>>>>>>
>>>>>> Sounds good to me.  I'd like to add that internally, we should make sure
>>>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>>>> conflict among ourselves.
>>>>>>
>>>>>
>>>>> Like a text file per capability, with some doc on the capability in the
>>>>> file? Files organized in a tree from the names?
>>>>>
>>>>> That sounds good; much better than some wiki.
>>>> +1
>>>> I don’t know enough about this yet to suggest a format, but having it somewhere in the source is a lot better than a wiki. A wiki brings to mind that horrible log ids page we used for AS 7.
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Capability naming conventions

Brian Stansberry
In reply to this post by Brian Stansberry
Status update:

I've done the adoc thing and made the repo official by cloning it from
my personal github to the wildfly account:

https://github.com/wildfly/wildfly-capabilities

Further updates should be done via pull requests there.

On 6/19/15 8:37 AM, Brian Stansberry wrote:

> Thanks; that's a good idea.
>
> On 6/19/15 8:18 AM, Max Rydahl Andersen wrote:
>> Just one quick suggestion.
>>
>> Instead of .txt, use .adoc then it will actually render nicely on github
>> out-of-box and you get access to
>> do tables and lists etc. in something that is readable as text and look
>> nice rendered.
>>
>> /max
>>
>>> On 6/13/15 4:00 AM, Kabir Khan wrote:
>>>>
>>>>> On 12 Jun 2015, at 22:31, Brian Stansberry
>>>>> <[hidden email]> wrote:
>>>>>
>>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote:
>>>>>
>>>>>>
>>>>>> Sounds good to me.  I'd like to add that internally, we should make
>>>>>> sure
>>>>>> we continue to maintain some registry of our org.wildfly name spaces
>>>>>> somewhere (maybe even just a git repository would be OK) so we don't
>>>>>> conflict among ourselves.
>>>>>>
>>>>>
>>>>> Like a text file per capability, with some doc on the capability in
>>>>> the
>>>>> file? Files organized in a tree from the names?
>>>>>
>>>>> That sounds good; much better than some wiki.
>>>> +1
>>>> I don’t know enough about this yet to suggest a format, but having it
>>>> somewhere in the source is a lot better than a wiki. A wiki brings to
>>>> mind that horrible log ids page we used for AS 7.
>>>
>>> How about this?
>>>
>>> https://github.com/bstansberry/wildfly-capabilities
>>>
>>> The README.md explains things pretty clearly.
>>>
>>> At this point it just has the capabilities currentl in core, including
>>> unmerged ones added in the PR at
>>>
>>> https://github.com/wildfly/wildfly-core/pull/810
>>>
>>> That repo has a LICENSE file, which specifies ASL 2.0. I don't know if
>>> such a thing is really necessary, or if some other license, like
>>> Creative Commons, is more appropriate.
>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> /max
>> http://about.me/maxandersen
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev