[
Lists Home |
Date Index |
Thread Index
]
Rick Jones wrote:
> yet another newbie stumbles into the maze of twisty TLA's all similar
> but different...
This is so refreshingly different from the theological exegesis usually
practiced around here.
> long ago and far away (first public distribution in 1993), i
> wrote/edited a benchmark called netperf (http://www.netperf.org/)
Heh-heh in 1990 I wrote Bonnie, now in yer basic linux distro, still
gloriously free of anything but line-oriented input and output. Hmmm
> now I'm looking to abstract further, and someone suggested that XML may
> be the way to go. i am looking for a more flexible config format and
> message passing mechanism, and reporting.
Yup, seems like if you're going to go to the work of rejiggering this
stuff, you might as well XMLify it, the alternative is inventing your
own new syntax which is just not a good way to spend time.
>
> notice that there is a dependency between test 2 and test 1 - test 2
> needs to know what the dynamically alolcated port number used by test 1
> happens to be before it can establish the data connection.
Right, so the sequence is important. Right off, you have to decide
whether the whole exchange is one big XML doc from start to end, or
whether you're going to open a channel and send along a series of
smaller XML docs. I suspect the latter will be slightly less
programming work - you can bash each little XML message into a DOM or
other in-mem structure as it arrives, whereas in the on-doc approach
you're really going to need to deal with individual elements as they
show up on the wire.
>
> having become totally confused by C++ several times, and wanting more
> low-level control over sockets than I understand is available in Java,
> and wanting to use things like libcurl for the FTP and HTTP i would like
> to stick with C
Hear, hear.
> using XML as the output format of the benchmark appears appealing - the
> stuff I wrote to parse netperf2 output for the netperf database was,
> well, quaint.
Yep, probably the best reason.
In your example: I'm not sure why it's a good idea to put
platform-specific stuff into separate namespaces. Not sure it's a bad
idea either, but aren't a lot of them going to share a lot of fields?
> *) i'm not sure when one "should" use attributes versus a nested element
Someone already pointed you at Robin's assemblage, which you should
read. The important thing is not to lose sleep over it because (gasp)
it isn't that important.
> *) my config files may become quite large - XInclude sounds interesting,
> but a fully formed file XIncluded (at least via libxml) has the whole
> file as a sub-element when what I really want (I think anyway) is the
> elements in the file being included be at the same depth as the include
> itself (ie up one level)
XInclude is ok, but not yet widely implemented so you may have to cook
your own; which wouldn't be that hard. Or you could just assemble the
chunks programmatically, in your own code or via XSL. The latter is
probably more flexible arechitecturally, but has the downside that
you'll have to learn XSL first.
I'd advise against using entities
> *) since I am interested in things like doubles and 64-bit integers and
> such i think i want to use XML schemas (?) but those seem to be still
> rather new and not part of libxml - are they part of any other C-based
> offering.
Writing a schema or a DTD or a RelaxNG (check out the latter if you
haven't seen it yet) is a valuable exercise for helping shake out your
design in your head. Having said that, don't worry too much; just
encode the numbers in text in the obvious way with digits and +/- and
decimal point if required, write some human-readable documentation as to
what they represent, and let the programmers figure it out. A perl
programmer's just gonna dump them all into scalars anyhow :)
> *) when someone adds a new test suite, I'd like them to be able to
> include a validator (schema?) that will be sucked-in to the main config
> file. however, i'm concerned about what I read about namespaces (which I
> think I may need/want to avoid name conflicts) and validation, and it
> seems that the validators have to be all specified at the top of a
> document?
Practices vary. Validators are indeed good. My suspicion is you'll be
happier with RelaxNG as a basis, but check out the options.
Glad to hear that netperf's getting dragged into the new millenium! -Tim
|
