rkdavis at burninghorse.com
Thu Aug 1 21:24:42 UTC 2002
Ryan Eatmon wrote:
>I fear that in time we will run into a wall and
>iq:stats will not scale.
as iq:stats is mainly aimed at a corporate environment that is definatly
>I know that the JEP states that you can always make a new namespace to hold
>more stats in whatever format you want, but I think that's a bad idea too. I
>also know that the JEP states that a service can toss in a new stat by just
>creating a new tag, but I think that is an even worse idea. It might be
>valid XML, but just because you can do something doesn't mean you should.
>Rather than fix the namespace to four, ten, or twenty tags, make it more
>generic and leave it open for expansion in the future. The idea behind a stat
>is that you want to ask for something and get the data back.
I definatly like that much better than hardcoding core stats which
although was my idea it was pretty aribtary with both the number and
choice of elements. I think Ryan is correct and i will rework the draft
over the next couple of days to make the changes. thank you for the
>Finally, my last suggestion that goes hand in hand with this is to look to the
>JANA, (term coined by hildij) the Jabber Assigned Names Authority, to maintain
>the list of stats and their formats. uptime is a stat, but what format does
>it come back in? seconds? HH:MM::SS? The JANA can maintain the list of JSF
>endorsed stats and what format they are so that everyone can speak the same
>The JANA is going to be setup to maintain the list of types/categories for
>browse and disco, and I'd would like to see this kind of thing maintained
>there also, as well as future JEPs that need this kind of centralized body.
although the draft did state that uptime was returned in seconds as is
iq:last it might be sensible to use JANA for as much as possible so
there are no ambiguities. Again a great suggestion and one i will look
thank you for the feedback etc.
More information about the Standards