[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Requirements Feedback



Some questions regarding some of the SMIng requirements.

1.  Can someone please elaborate on the differences between #14 (Instance
Pointers) and #15 (Row Pointers).  Can they be thought of in this way?
Instance pointers are typed pointers, whereas row pointers are void
pointers.  With the distinction being that an instance pointer may only
reference a row in one type of table, while a row pointer may reference a
row in any kind of table?

2.  In example for #20 (Events), the event linkDown has (or seems to have)
two attributes - one of type status and a description.  Is it possible to
have more attributes for an event?

3.  #28 (Categories) - is this akin to C++ namespaces (apologies to those
who are not familiar with them) in that they allow for scoping in order to
reduce/prevent name collisions?  Or, is this the purpose of #68 (Module
Namespace)?  If #68 serves this purpose, I would like some more
clarification on #28 so that I can get them straight in my mind.

4.  I would like to second the idea that #29 (Agent Capabilities) be removed
from the SMIng requirements.  This does not seem to belong at this level.

5.  Would it be possible to name #33 (Classes) to something like "Attribute
Groups"?

6.  #39 (Arrays) - is this as Andrea thought (a multi-valued attribute), or
is it a set of multiple attributes?  I can see use for having a set of
multiple attributes (which is what I had thought it was).

7.  Am I right in assuming that #64 (Make Status Information Optional)
refers to status information that is most useful to a human?  For example,
if something is deprecated, a compiler could inform the user that they are
depending on/deriving from/referenceing something that has been deprecated
in a manner similar to how the Java compiler does.  If we go down the path
of keeping the status information for the purpose of providing meaningful
information from compilers, do we go down the road of also supplying
additional information.  For example, in the case of a deprecated class that
is inherited from, should there also be information that states the name of
the new class that should be inherited from instead?

Thanks.
Jamie

----------------------------------------------------------------
Jamie Jason                       email: jamie.jason@intel.com
Intel Architecture Labs           phone: 503-264-9531
2111 NE 25th Avenue               fax:   503-264-9428
Hillsboro, OR 97124
                          
"To give anything less than your best is to sacrifice the gift."
 - Steve Prefontaine

All opinions expressed are:
1.  Entirely my own.
2.  Not necessarily shared by my employer.
3.  Unencumbered by the thought process.
----------------------------------------------------------------