10:22 p.m.
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
11:24 p.m.
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
11:30 p.m.
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>
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
https://lists.jboss.org/mailman/listinfo/wildfly-dev
11:31 p.m.
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
11:34 p.m.
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>> 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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
11:41 p.m.
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> 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>> 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
>
--
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
12:20 a.m.
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
<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
>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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
11 a.m.
On 12 Jun 2015, at 22:31, Brian Stansberry
<brian.stansberry(a)redhat.com> 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
10:17 p.m.
On 6/13/15 4:00 AM, Kabir Khan wrote:
> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry(a)redhat.com>
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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
9:28 p.m.
On 6/13/15 4:00 AM, Kabir Khan wrote:
> On 12 Jun 2015, at 22:31, Brian Stansberry <brian.stansberry(a)redhat.com>
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
3:18 p.m.
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> 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
3:37 p.m.
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> 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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
1:51 p.m.
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
<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
1:54 p.m.
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>
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
2:33 p.m.
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>
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
--
- DML
2:46 p.m.
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> 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
>
3 p.m.
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
<brian.stansberry(a)redhat.com> 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
--
- DML
10:05 p.m.
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
>>>> <brian.stansberry(a)redhat.com> 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
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
3219
days inactive
3240
days old
17 comments
6 participants
participants (6)
-
Anil Saldhana -
Brian Stansberry -
Darran Lofthouse -
David M. Lloyd -
Kabir Khan -
Max Rydahl Andersen