Matt, thank you for your thoughtful response. Here is (yet another) a continuation of this discussion.
----- Original Message ----- > if you read the original email.. i was talking about the way we are doing > things now. right now we are not grouping metrics in any way. each > message is 60 bytes including the header. > > i just didn't mention the inheritance model that we've talked about > before. in my early tests i used inheritance to make the xdr message > smaller.. we've discussed that. most groups of metrics will have very > similar metric attribute so.. we'll only need to send them once. This point (XML vs XDR on wire) is mute from your recent email, but inheritance is definately an important feature that will (in the normal case) reduce message sizes significantly. > > yellow flag. foul. you cannot use my own argument against me. :) we > talked about this before and i expressed my fear of translating strings to > doubles and back again... it's not an issue here. i'm not taking ascii > and converting it to binary .. storing it.. and then translating it back > to ascii for xml... instead.. i'm saying.. we store everything as ascii. I dont understand. Floats and doubles often will be generated in binary. For example a detailed running time from MPI_Wtime() or a GPS coordinate. No matter how you slice it, storing it in ascii means a conversion. That conversion looses precision. We could store the exponent and mantissa as separate integers in ascii, but that is a different strategy with its own problems. > > > World:US:California:Berkeley:UCB:Millennium::mm56:cpu:number > > > > > > so here is how the URL is read.. i'll call the data between the > > > delimiters > > > tokens. > > > > If this is just locating a part of an XML tree, why do we need the > > "organizational unit" special delimiter? Why not a straight XPath-like > > expression. [...] > > i forgot to mention that a host token can be empty for summary > information. for example... > > World:California:::cpu:number > ^^-------------- empty host token > > would point to the number of cpus available in California... in xml... > I still dont see the need for the unique organizational unit delimeter. Perhaps I'm missing something. > i still have some more work to do on the tree library side of things but > i'm close. the demo that i showed you doesn't understand the tree path > shorthand... it just assumes all tokens are equal in function. it will be > quick for me to add that functionality. once i have the tree structures > working as i like.. it shouldn't take me long as you say to get gmetad3 up > and going. I look forward to the full tree data structure. Federico
