6:51 a.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