[standards-jig] JEP-0039 (Statistics Gathering): The argument for <item/>

Robert Norris rob at cataclysm.cx
Sun Nov 10 23:17:32 UTC 2002


> The latest version of JEP-0039 removed the <item/> element, presumably
> because lists (of JIDs) are redundant.  And this is true, since disco
> and browse handle this just fine...for JIDs.  But then how could I use
> disco or browse to present my GPS "statistics", or the throughput (by
> session) from a JOBS server?

The way I've been thinking of the stats JEP is as way of checking the
value of counters (packets in, users online, server uptime, etc). I
argued against the inclusion of a way to retrieve lists of JIDs for two
reasons:

 - as you note, browse/disco cope with this just fine
 - to me, a statistic means a value that cannot identify the original
   data that caused the statistic to be generated. A list of JIDs is not
   this, nor is specific information such as GPS position.

> The use of <item/> lists in stats would allow for a lot of flexibility,
> without necessarily increasing the complexity that much.  Also, this
> most likely reduces the amount of record-keeping JANA is responsible
> for, since "nested" stats wouldn't need to register each little piece.

While I realise that it is not much additional complexity, I would vote
against it for reasons of correctness. stats is not supposed to be a
catch-all data collection protocol.

> EXAMPLE:  It was brought up that it might be very desirable to get a
> count of the categories of packets that are sent/received.  In that
> example, a lot of "overloading" of the <stat/>'s name attribute was
> used.  I would argue that this is more cleanly handled with <item/>:
> 
> <stat name='jabber/packets' units='packets'>
>   <item name='in' units='bytes'>12301571714</item>
>   <item name='out' units='bytes'>12341097132</item>
>   <item name='iq/in'>405624</item>
>   <item name='iq/out'>435123</item>
>   ...
> </stat>

The first two stats feel wrong to me (since their type is 'bytes', but
we requested packets) - is it right to overload like that?

IMO, the correct way to do that is just to send a seperate request for
each, eg:

S: <iq type='get' to='jabber.org'>
     <query xmlns='http://www.jabber.org/protocol/stats'>
       <stat name='bandwidth/packets/in'/>
       <stat name='bandwidth/packets/out'/>
       <stat name='bandwidth/packets/iq/in'/>
       <stat name='bandwidth/packets/iq/out'/>
     </query>
   </iq>

R: <iq type='result' from='jabber.org'>
     <query xmlns='http://www.jabber.org/protocol/stats'>
       <stat name='bandwidth/packets/in' units='packets' value='123456'/>
       <stat name='bandwidth/packets/out' units='packets' value='234567'/>
       <stat name='bandwidth/packets/iq/in' units='packets' value='3456'/>
       <stat name='bandwidth/packets/iq/out' units='packets' value='4567'/>
     </query>
   </iq>

> EXAMPLE:  One of the examples that had been in JEP-0039 was reporting
> GPS coordinates.  Without <item/>, this gets cumbersome.  With <item/>,
> it's more encapsulated:
> <stat name='x-app/gps' units='decimal-degrees'>
>   <item name='latitude'>N49.25903</item>
>   <item name='longitude'>W122.77428</item>
> </stat>

This is specific information, and so isn't a statistic. Why not just
create a seperate namespace to do this?

S: <iq type='get' to='rob at cataclysm.cx/laptop'>
     <query xmlns='http://www.jabber.org/protocol/location'/>
   </iq>
       
R: <iq type='get' to='rob at cataclysm.cx/laptop'>
     <query xmlns='http://www.jabber.org/protocol/location'>
       <latitude>N49.25903</latitude>
       <longitude>W12277428</item>
     </query>
   </iq>

> EXAMPLE: In JOBS, it might be a really good idea to get the throughput
> rates for various sessions.  Including <item/> can facilitate this:
> <stat name='jobs/throughput' units='bytes/sec'>
>   <item name='session:01234567'>1024</item>
>   <item name='session:01234213'>550624</item>
>   ...
> </stat> 

Again, why not just request the list of stats available, and then send a
request for the ones you want?

Sorry if I sound a bit harsh, but I really would like to limit this JEP
to a simple mechanism of requesting counter information, and nothing
more. That keeps it really easy to implement :)

Rob.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20021111/ef1177c5/attachment.sig>


More information about the Standards mailing list