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?

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 <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com>> 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 wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> 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 <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com> > <mailto:david.lloyd@redhat.com <mailto:david.lloyd@redhat.com>>> 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 > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list &gt;wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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.

> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry(a)redhat.com&gt; 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 > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 6/13/15 4:00 AM, Kabir Khan wrote: > >> On 12 Jun 2015, at 22:31, Brian Stansberry >> <brian.stansberry(a)redhat.com&gt; 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 >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 >>>> <brian.stansberry(a)redhat.com&gt; 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 >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > /max > http://about.me/maxandersen

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 <brian.stansberry(a)redhat.com&gt; 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 >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 <brian.stansberry(a)redhat.com&gt; 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 >>>> wildfly-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev