[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
>
> 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.
That just zoomed miles above my head, and I am often described as
utilizing polysyllabic verbiage in interpersonal communications :)
> > 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
Amazing how a good idea has legs isn't it :)
> > 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.
And these days I feel compelled to be able to add new TLAs to my
resume...
> > 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.
I figure the intial configuation data is (at least conceptually) one big
XML document and the netperf controller would have one big in-mem
structure (presently what libxml2 would give me). Indeed, I figured on
sending mini-docs of XML to the individual tests.
The reason I mentioned the interdependence between some tests was an
obtuse way of trying to ask about ID and IDREF attributes I suppose.
When it comes time in the netperf controller to send setup information
to the dependent test I want to be able to lookup the dependent stuff
with reasonable simplicity and dispatch. I figured then that I would
need/want to use ID and IDREF attributes.
> > 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?
Well, I sort of slid into the idea of using namespaces. Basically, I
wanted some way to isolate/identify test-specic things such that while
the netperf controller was parsing the big config file (or intially
parsing a message) it could see "ah hah, this part is only groked by the
nettest_bsd test-specific "parser" - I wanted to layer/isolate/whatever
things so netperf itself wouldn't necessarily need to know about it
directly.
I was also hoping that there would be some way to have the test-specific
portions covered by their own validation rules such that the existing
XML/XSDL parsers/validators might do some of the config file and message
checking for me.
> > *) 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.
OK.
rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
|
