[
Lists Home |
Date Index |
Thread Index
]
Oh, a lovely discussion, full of background. Enough so that I can leave
out bits of context and perhaps earn an entirely undeserved reputation
for terseness ... *laugh*
On Tue, 2002-07-30 at 20:24, Rick Jones wrote:
> yet another newbie stumbles into the maze of twisty TLA's all similar
> but different...
xyzzy
Nothing happens.
> (I never went as far as XDR, not sure why - I guess that doesn't matter
> now though...)
An unconscious instinct for self-preservation, perhaps?
> i'm looking to have test suites be "plugins" (without full knowledge yet
> of what that may mean :) - which means that the base netperf may not
> know quite how to grok test-specific config info for a new test suite.
>
> a test instance would be in a number of "states" in its lifetime:
>
> new - the thread for the test instance was created
> init - the test is initialized and read to start
> load - the test is generating load
> measure - the test is measuring its generated load
>
> there would be messages passed between netperf and netserver to cause
> thse things to occur - there may also be other things like a kill
> message to kill a test with extreme predjudice and perhaps a request for
> intermediate results. some messages are of things completely known to
> netperf, some are likely to be rather test-specific. there is to be a
> single TCP connection between a netperf and a netserver overwhich will
> be multiplexed comms for the individual test instances living within
> that netserver.
Could I suggest that you take a look at the construction of Jabber?
There's an excellent (O'Reilly zoo) book on the subject. In particular,
the way that Jabber associates a namespace with a module is unique in my
experience, but might meet your needs quite nicely. It's a very
different take on the use of namespaces (and it has to be said that the
distributed code doesn't do a terribly spec-compliant job on namespaces;
change the prefix of the root element to anything other than "stream"
and it barfs all over your shoes). I won't completely recommend it, but
I think that you ought to look at it, as an inspirational text ....
Jabber config files address the same problem: independently written
modules, which may even operate on different machines, but for which
configuration should be centralized.
> <!-- I would like to be able to include a file of just test and server
> elements without a containing <netperf></netperf> -->
>
> <xi:include href="sub.xml" />
Whether inclusion works as planned may depend upon the processor used to
parse the instance. Check on what's available; you might find (for
instance) that the tools available in Python supply your needs, and that
the language is available on all platforms likely to use netperf.
> 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 (perhaps that shows my age :) i have come across libxml
> from the gnome folks - haven't gone quite as far as gdome2 yet though,
> peeked only a little at SOAP and am not sure I want to go that far just
> yet.
Daniel's a regular on this list, so perhaps he'll say something about
how well libxml2 suits your purposes.
> 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.
Take a quick look at ant, especially its optional junit task. No, I'm
not suggesting a unit testing framework, but the junit task generates
XML output, which is then transformed via stylesheet into a really
lovely tree. Moreover, the XML is still there, for further
transformation (as accumulation of data, or run comparisons ... just
another stylesheet).
> *) i'm not sure when one "should" use attributes versus a nested element
Controversial. Using DTD-defined XML, the only things that *could* have
types were attributes. Not true for XSDL-defined, or even RNG-defined.
There's a tendency among some to suggest "element-normal" presentation:
use an element for the "main" content; use attributes only for
meta-information. So <measure units="cm">123</measure>. On the other
hand, I've written entire XML languages (for populating a database, as
it happens) that had no element content. Everything done in attributes
(and with kindness ...).
> *) 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)
XLink replace. Or just live with inclusion semantics.
> *) 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.
May I point out that XML is text? So it really doesn't matter. You can
define it, in your application, as <element type="long-long"> and nobody
else has to care. Type definition is a seriously painful topic, because
XML's text representation doesn't really correspond to the binary
representation of a double or float, even using IEEE 754. You're
*going* to convert. If you were sending this information around to
other W3C XML Schema-aware applications, then you'd have a real need to
use the types defined by W3C XML Schema. Since you're using the types
where they need to turn into types (XSLT isn't going to perform special
actions based on types, not this year, anyway), you''ve no requirement
to conform to the truly limping and incomprehensible collection of type
collections defined in XSDL. Do it in the application.
> *) 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?
So define each test as a separate document. Validate independently.
Use XLink/XInclude to stitch together; use document() to produce
aggregated reports via XSLT.
> i'm sure that my questions show just how little I really understand
> about all this, so please be gentle :)
Heh. No, you ask really *nice* questions. Your questions can be
answered. Given the way that the questions are phrased, I can feel
confident that an answer that isn't an answer, just a pointer at
resources for you to find the answer, is still potentially useful. "I'm
new, could someone explain XML?" is a hard one ....
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
I have spent nights with matches and knives, leaning over ledges, only
two flights up. Cutting my heart, burning my soul. Nothing left to
hold. Nothing left, but blood and fire.
-- Indigo Girls
This is a digitally signed message part
|
