[wildfly-dev] Capability naming conventions

[David M. Lloyd]

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 at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML