Just spent hours tracking down the "DOCSIS TLV" config-file format and implementing it. This is one of those things where the project spec says "do what that spec says to do", pointing you at a deprecated version of the big spec, then the updated version of that spec says "do what this other spec says to do", but that spec is then defined in terms of 2 other specs... an enormous amount of reading to specify something that can be described in a tiny amount of code.
The key thing that gets left out AFAICS is that the spec is recursive; so for option 43.1, 43.2, or 43.3.4.5.2.3.4.5.6, for example, you do all of the encoding steps as though you were doing a top-level encoding for the various named (numbered) sub-options at each level, then you break the resulting (potentially very long) value into 255-byte chunks of top-level encodings. For instance, our last example there with a value of 'hello' looks like:
[43,21,3,19,4,17,5,15,2,13,3,11,4,9,5,7,6,5,104,101,108,108,111]
Once you actually get all that, it's one of those relatively simple specs that likely should just be wrapped up in a standard library... but that would be hundreds of times more work than putting together something that can do what you need for this tiny project.
There are likely stupid little corner cases, such as whether to do splitting of long option-values only at the top-level, or whether you are intended to also split them in the recursive elements if an individual sub-element is > 255 chars. There's also some checksums and the like, basically just some sha1 hashes.
The fact that you need lookup tables for all non-trivial interpretation makes the whole thing look way too messy to bother with beyond the needs of your clients of the day. In the example above, unless you know that 43.3 has internal structure you can't parse the result meaningfully. It might just as easily be a single long string. The T (type) in TLV is just a single-byte-integer reference into the current table space, not a direct data-type value. Those tables are vendor, and potentially even project, specific, so you then need to create a mechanism for users to define the tables... ick. Makes one appreciate context-free formats all the more.
Comments
2010-07-25 14:02
> and would have no Trac integ ration The trac-bzr plugin[ 1] seems to provide good integ ration between bzr and t [...]
2010-07-13 21:47
I've always been fascinated wi th the Asterisk AMI interface. So much so that I married tha t fascination with the [...]
2010-07-03 21:32
Yes, only references in dicti onaries are replaced, so hold ing references in lists, tuple s, etceteras keeps them alive.
2010-07-03 11:18
They hold references to remove and install?
2010-06-24 08:34
There's higher-level objects w hich are tracking what is repl aced (the actual Mock objects) . They hold references [...]
2010-06-24 08:23
I haven't tried it, but it see ms to me like this approach ha s one fundamental problem: If you replace all refs o [...]
2010-06-24 08:22
That's the "magic" that made m e go "ooh shiny"
2010-06-24 06:03
That's even more evil than the mock patch decorator...
2010-06-06 18:33
blush Oh.
2010-06-06 11:07
That's what the module does (a utomatically), but on a per-te st-run basis, and only for the process being tested (i [...]
2010-06-06 02:43
Maybe I'm missing something im portant here, but why not just write small scripts to mimic whatever dangerous utili [...]
2010-06-05 15:17
I thought about stubbing out t he python call to the process in the current process, but I want something which stu [...]
2010-06-05 14:47
Hmm... if Mock isn't flexibl e enough to handle mocking pro cesses adequately then I'd lik e to know how it could b [...]
2010-05-19 10:27
Hey, maybe it's a stupid new bie question, but where and ho w exactly should the patching of the core take place? [...]
2010-05-04 14:36
I used Qemu and VirtualBox pre tty extensively back when I wa s working for the OLPC, but mo st of the stuff we were [...]