I've been looking at the SNMP v1 and v2 RFC's, including the MIB and SMI RFC's (a Management Information Base is writen in an Abstract Syntax called "Structure of Management Information") Specifically, I've been looking at the textual convention "physAddress".
Here is an IMPORT declaration a private MIB I'm using:
PhysAddress FROM RFC1213-MIB
and here from rfc2011 (1996):
PhysAddress FROM SNMPv2-TC
RFC4181(2005) notes that SNMPv2-TC is RFC2579 (1999)
...And some MIB compilers don't require the IMPORT statement for PhysAddress.
What is the canonical form of the declaration? Would a different MIB compiler reguire an import from RFC2579 rather than SNMPv2-TC? Is there a canonical form? If there is a canonical form, where is it documented?
The rule is that for any SNMP MIB compiler, they only care about the module name in a document. For example,
SNMPv2-TC DEFINITIONS ::= BEGIN
in RFC 2579 document indicates that it defines a new module called SNMPv2-TC.
Of course you can import "RFC2579" but there needs to be a corresponding module defined anywhere (but it was never a valid module name in RFC space).
Some compilers, such as MG-SOFT's, decide to treat basic types as built-in types, and users of such products needn't worry about where to import them. That might resolve some issues, but can also lead to others.
I think you just wonder why there is also a PhysAdddress in RFC1213-MIB module. That's because RFC1213-MIB was defined to accompany other SNMP v1 components.
So hints for you are,
Make it very clear which SMI version you want to use, v1 or v2.
When authoring the MIB documents, only use the references (via imports) that are compatible to the SMI version you choose. RFC1213-MIB is for SMI v1, while SNMPv2-TC is for SMI v2.
If you check the standard MIB documents from IETF, or big firm like Cisco, you will see that in most cases they follow the hints.
Related
Is there a convention for naming Scheme libraries? I am thinking of using reverse domain name notation, similar to Java's convention. For example, (define-library (com example mylib) ...) or (define-library (com.example.mylib) ...). Is there a general guideline for naming Scheme libraries (other than avoiding the use of scheme and srfi as the first identifier in the library name)?
http://www.r6rs.org references "Revised6 Report on the Algorithmic Language Scheme — Non-Normative Appendices"
PDF | HTML
Appendix G addresses this issue:
Programmers should choose names for distributed libraries that do not collide with other libraries’ names. This appendix suggests a convention for generating unique library names, similar to the convention for Java [1].
A unique library name can be formed by associating the library with an Internet domain name, such as mit.edu. The lower-case components of the domain are reversed to form a prefix for the library name. Adding further name components to establish a hierarchy may be advisable, depending on the size of the organization associated with the domain name, the number of libraries to be distributed from it, and other organizational properties or conventions associated with the library.
Programmers should use library names that are suitable for use as part of file names. Special characters in domain names that do not fit conventions of commonly used file systems should be replaced by hyphens or suitable “escape sequences” that, as much as possible, are suitable for avoiding collisions. Here are some examples for possible library names according to this convention:
(edu mit swiss cheese)
(de deinprogramm educational graphics turtle)
(com pan-am booking passenger)
The name of a library does not necessarily indicate an Internet address where the package is distributed.
Recently I started studying go-ethereum and this was my first time using golang. C++ is my main language and I'm a bit puzzled due to variable names in go-ethereum project.
core/state/managed_state.go:25:type account struct {
core/state/state_object.go:98:type Account struct {
There are both "account" and "Account" types in state package, which seems weird.
I've checked Naming convention for similar Golang variables, and it still looks terrible.
And what I've found is that they use a lot of "Node" struct in different packages. Definitely they do have different purposes and structures.
Are these kinds of naming is convention and popular in golang?
If you have any good references for naming convention in golang (e.g. open source projects or books), could you please name some of them? It would be really appreciated.
There are both "account" and "Account" types in state package, which seems weird.
There is a meaningful difference between these two names in the language specification.
From the Go Language Specification:
An identifier may be exported to permit access to it from another
package. An identifier is exported if both:
the first character of the identifier's name is a Unicode upper case
letter (Unicode class "Lu"); and
the identifier is declared in the
package block or it is a field name or method name.
All other identifiers are not exported.
So, taking a closer look at the go-ethereum codebase, here are my observations:
type account in managed_state.go is an internal implementation detail, providing a type for the accounts field in the exported ManageState struct
type Account in state_object.go is an exported identifier
I think the implementation choice make more sense when you look at the generated documentation.
In particular, the Account type is front and center, detailing a data structure that's of interest to consumers of the package.
When you look at the documentation for the ManageState struct, the unexported fields are purposely not documented. This is because they're internal details that don't impact the exported interface and could easily be changed without impacting users of the package.
In regards to naming recommendations, see the Names section in Effective Go.
When creating a FHIR ValueSet using ALL codes of a small externally defined code list, which would be more appropriate (and indeed correct per the FHIR specification) - a composition or an inline codeSystem?
As an example, creating a ValueSet from the following code list:
http://www.datadictionary.nhs.uk/data_dictionary/attributes/e/end/ethnic_category_code_de.asp
Would there be advantages/disadvantages of using either method?
Inline definition of a code system is used when the code system and value set are synonymous - you're inventing codes and saying the value set contains all of them. Places this occurs are when we're defining structural codes for FHIR (ones that we'll be maintaining rather than external organization) or for things like Questionnaires where the codes might be specific to that particular questionnaire. In general, inventing your own code system isn't encouraged because it's less likely people will recognize it. It's better to draw codes from standardized code systems, be those international (like SNOMED, LOINC, ICD9, etc.) or national or even organization-maintained code systems.
I have some questions on package naming for external Go libraries.
I am interested if using generic names like "text" is considered a good practice? Having in mind that I cannot declare a "nested package" and that the library I am building deals with text processing, is it ok to have the package named "text" or should I stick to the library name as a package name too?
I am building a set of libraries (different projects) and I want to combine them under the same package. Is this also problematic? I am new to the Go community and am still not sure if package pollution is a problem or not (I do not see a problem as long as I import few packages in my code).
The reference on that naming topic is "blog: Package names"
It includes:
Avoid unnecessary package name collisions.
While packages in different directories may have the same name, packages that are frequently used together should have distinct names. This reduces confusion and the need for local renaming in client code. For the same reason, avoid using the same name as popular standard packages like io or http.
Check also your package publishing practice, as it will help disambiguate your "text" package from others.
As illustrated in "An Introduction to Programming in Go / Packages":
math is the name of a package that is part of Go's standard distribution, but since Go packages can be hierarchical we are safe to use the same name for our package. (The real math package is just math, ours is golang-book/chapter11/math)
When we import our math library we use its full name (import "golang-book/chapter11/math"), but inside of the math.go file we only use the last part of the name (package math).
We also only use the short name math when we reference functions from our library. If we wanted to use both libraries in the same program Go allows us to use an alias:
import m "golang-book/chapter11/math"
func main() {
xs := []float64{1,2,3,4}
avg := m.Average(xs)
fmt.Println(avg)
}
m is the alias.
As mentioned in the comments by elithrar, Dave Cheney has some additional tips:
In other languages it is quite common to ensure your package has a unique namespace by prefixing it with your company name, say com.sun.misc.Unsafe.
If everyone only writes packages corresponding to domains that they control, then there is little possibility of a collision.
In Go, the convention is to include the location of the source code in the package’s import path, ie
$GOPATH/src/github.com/golang/glog
This is not required by the language, it is just a feature of go get.
I'm using sharpsnmplib open source library to compile MIB files and use them in my custom snmp browser. The issue is that sharpsnmplib cannot compile RMON2-MIB file. And subsequent libraries that use it cannot be compiled as well. As it turns out, the (first) issue is with the text (RMON2-MIB.txt):
LastCreateTime ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This TC describes an object that stores the last time its
entry was created.
This can be used for polling applications to determine that an
entry has been deleted and re-created between polls, causing
an otherwise undetectable discontinuity in the data."
SYNTAX TimeStamp
Sharpsnmplib’s textual convention interpreter contains this text:
/*
* RFC2579 definition:
* Syntax ::= -- Must be one of the following:
* -- a base type (or its refinement), or
* -- a BITS pseudo-type
* type
* | "BITS" "{" NamedBits "}"
*
* From section 3.5:
* The data structure must be one of the alternatives defined
* in the ObjectSyntax CHOICE or the BITS construct. Note
* that this means that the SYNTAX clause of a Textual
* Convention can not refer to a previously defined Textual
* Convention.
…
Sharpsnmplib interpreter’s source
RMON2-MIB
RFC 2579
Interesting thing is that TimeStamp IS the textual convention defined in the SNMPv2-TC. And RMON2-MIB defines its own textual convention that uses TimeStamp. There are several other textual conventions in the RMON2-MIB that refer textual conventions from other MIB files.
Thus, if I’ve got it right, RMON2-MIB violates RFC2579. But this doesn’t make sense if RMON2-MIB is actively used MIB file.
What am I missing? How should the RMON2-MIB be properly interpreted?
First, #SNMP's open source MIB parser SharpSnmpLib.Mib is buggy and obsolete, as #SNMP Pro has a new SharpSnmpPro.Mib.
The code you found was even older (my handmade version), so I never expected it able to parse difficult MIB documents.
Second, RMON2-MIB is a very complex one, as it does rely on both SMIv2 core MIBs, as well as several SMIv1 ones. That requires you to have all dependencies properly located (using the correct copies, instead of downloading corrupt ones from the Internet).
Third, there is no conflict between RFC 2579 and RFC 4502 (RMON2-MIB). RMON2-MIB defines its own textual convention that uses TimStamp and that's nothing special or wrong.