[brlcad-tracker] [ brlcad-Feature Requests-3157347 ] Add support for namespaces in database

[SourceForge.net <no...@so...>]

Feature Requests item #3157347, was opened at 2011-01-13 09:41
Message generated for change (Comment added) made by tbrowder2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=640805&aid=3157347&group_id=105292

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modeling
Group: Major Effort
Status: Open
Resolution: Accepted
Priority: 9
Private: No
Submitted By: Tom Browder (tbrowder2)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for namespaces in database

Initial Comment:
For my own use I have started using the attr feature to add a "{namespace} {Mantech}" attribute pair to the _GLOBAL object as well as other useful attributes.  The namespace let's my TGM users know to expect certain attributes on objects, etc.  For instance, old TGMs used material codes from PDAM or COVART.  I use _GLOBAL to add an attribute pair "{material_codes} {COVART}" or ""{material_codes} {PDAM}" to let the user know what the material codes are.  More modern practices use attributes on objects, e.g., "{MUVES_component}", and for our vulnerability tool VALUE on each region I use, e.g., "{VALUE_material} {STEEL}" instead of a material code.

The capability to use multiple namespaces could be done now i believe through a system where one would use something like "{namespace}{mt}" to indicate all unqualified attributes are from the "mt" namespace--no registration needed EXCEPT all hard-wired BRL-CAD attributes would have to have something like "std:" as a prefix. e.g., "std:region" or "std:material_t".  Then the default namespace would be "{namespace}{std}", even if not explicitly shown on _GLOBAL.

On a voluntary basis, user namespaces could be registered along with any attributes registrants would like to be to made public.  BRL-CAD would incorporate such data into its libraries and provide an API to extract the data for use.

The minimum feature that would need to be done first is to provide a minimal set of registered attributes in the "std" (default) namespace and an API to access them.

----------------------------------------------------------------------

>Comment By: Tom Browder (tbrowder2)
Date: 2011-01-15 05:52

Message:
I would like to register "ManTech" (and alias "mti") for any name space
registry that is started for BRL-CAD.

----------------------------------------------------------------------

Comment By: Tom Browder (tbrowder2)
Date: 2011-01-13 10:09

Message:
Wow, I didn't even think of the namespace as applied to the whole database,
but it only make good sense.  And the uses for concatenation are legion! 
Nice--can't wait.

----------------------------------------------------------------------

Comment By: Sean Morrison (brlcad)
Date: 2011-01-13 09:58

Message:
Funny you should mention namespaces.  The work going into the Geometry
Service has resulted in a lot of discussion regarding the need for proper
namespace support.  It's likely a feature that will be implemented this
year, though with considerable changes on the implementation detail.

I'll see if the current thoughts can get documented up on the wiki so we
can discuss in more detail.  The basic idea, though, is that .g files would
become implicit file-scoped namespaces with the possibility of file
namespace overrides.

So as example, a model.g file would have a model.g implicit namespace or a
default namespace set on _GLOBAL.  Individual objects become scopeable
through naming convention, sph.s in model.g could be referenced as "sph.s"
which would imply the default namespace or with an explicit namespace such
as "covart::sph.s".  Using that, you can then always merge two .g files
without naming conflicts with a simple three-way merge selection.  Example
merging two files:  A.g + B.g -> C.g would mean either
  1) C.g gets A:: as default and B:: explicit,
  2) C.g gets B:: default and A:: explicit, or
C.g retains implicit C:: so both A:: and B:: become explicit. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=640805&aid=3157347&group_id=105292