7:46 a.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
>