Bug 541

FUI, it's really, really, really hard not to be incredibly sarcastic responding to a bug with this title, but I'll give it a try ...

The whole point of the names code that you should be able to refer to objects by names such as /Names/server/ath0.  If names.cc regietered a namespace object just like node-list.cc then it would have the same capabilities as NodeList.  You would have paths that looked like /Names/0/devices/4/ intead of /NodeList/0/devices/4.  What would be the point?

It seems to me that in order to do what you suggest is not weird and wire in the names system as if it were any other namespace, you need to be able to dynamically create attributes associated to an object at run-time.

In this case, to do the above, you would have an object /Names which you register as a root namespace.  When someone names an object "under" a path segment in this namespace you would have to dynamically create an attribute called, for example, "server" on the object /Names.  The Object pointed to by the value in the "server" might in turn have some nuber of attributes dynamically created one of which is "eth0".  

The problem with this picture is, unless I am horribly mistaken, Attributes are class-based, not object-based.

Another way of doing this is to not invent a new dynamic attribute system, but provide the ability to name objects.  That's why I called it the object name service.  In this case, the naming subsystem is not integrated into the config path parser, the Attribute system and Objects directly, it is used by them.

That is how it is implemented and the "weird" code I think you are talking about is to handle the difference between a path composed of class-based non-dynamic Attributes and a path composed of dynamic name aliases.  There is also "weird" code to allow mixing and matching of the kinds of paths, for example, "/NodeList/0/eth0".

The implementation as it stands allows for fast lookups of names, integrates with config completely and doesn't require inventing new dynamic Attribute powers.  It is not broken -- it works exactly as designed.  There is inline documentation that, IMO, describes exactly what is going on.

My take on this is if you find an instance where this implementation doesn't work, file a bug describing how it is broken.  If you think there needs to be more documentation, please file a bug saying that more inline documentation would be helpful -- specifying where your confusion is would be great.  If you want to provide an alternate implementation you think is superior, patches are welcome.  

Given that the code works as designed and you identify no problem, I think a reasonable bug might ask for a manual chapter on the object name service and more examples.  Saying the code is weird is simply meaningless, so I am marking this bug invalid.

1) If there is a need to hook into the namespace resolution process, we should add a hook to do this rather than hardcode the /Names resolution code in config.cc
2) I expected the code to exactly what you describe, that is, use attributes to make this work

So, to summarize, yes, I agree that the bug report title is not clear but the main purpose of this bug is to point out that, while it was never explicitely documented as such (my fault entirely), the design of the src/core/config.cc code was to _never_ hardcode any namespace per-se which is why I think that it is wrong to do this for /Names. 

So, yes, I will try to figure out a way to pull this out. Can you please keep this bug open to make sure I don't forget about this ?

Then can you please come up with a name that describes what the issue really is?  

How about 

"/Names string hardcoded in config.cc" 

or

"Need ability to create attributes at run-time to support config path segment aliasing"

The current title of this bug is ridiculous.