[Ns-bugs] [Bug 541] Names implementation really weird

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=541


Craig Dowell <craigdo at ee.washington.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |craigdo at ee.washington.edu
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Craig Dowell <craigdo at ee.washington.edu>  2009-04-06 23:42:18 EDT ---
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.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.