racluster request

[Denton, Rick]

> Hey Rick,
> Oh, I had a simple suggestion.  I can add a "cont" flag to 
> help you get what you're interested in.  One problem with 
> your original suggestion is that it changes the whole 
> paradigm, so that older confif's would no longer work, this 
> would avoid that problem.
> 

yea.. this is along the lines of my original thinking tho reversed
logic..
with a 'final' flag instead of a 'cont' flag either way :)..

this extends it a fair bit with minimal change to existing setups which
is a good thing.

it isn't as flexible as it could be but adding the flexibility would
break existing stuff which is bad but may be handy..

however, using a format like that from my last rant could potentially do
both.. but is more effort.. but gets the flexibility and the parser for
the tree building should parse single entries also as a boring tree full
of leaf nodes so _could_ remain compatible with existing racluster
config files?

this again is not as flexible as full flow control language or the named
trees and jumping around bizzo but that is probably being all about the
journey rather than the destination :).. ie entertaining to conceive but
doesn't warrant the usefulness of the gained functionality :)

> The "-M ramon" operation causes the program to duplicate the 
> record and reverse all the fields.  That may seem weird at 
> first, but what it does is remove all the directional 
> semantics.  What you end up with is all the objects are now 
> in the 'src' fileds, and the metrics represent transmitted 
> and received.  May seem weird, but it works.

:/...

yea.. which is really what i want in my particular case here.. (back to
direction based).. but i've never been able to reproduce it, break it
all down and put it back together again such that it adds up.. i should
ahve another look at it it has been a while :\