[standards-jig] jabber:iq:stats

Ryan Eatmon reatmon at mail.obelisk.net
Thu Aug 1 14:16:43 UTC 2002


I like the idea behind iq:stats and agree that we need it so that
administration can be made easier.

I'm still concerned about locking into a fixed namespace like we did with
iq:register and iq:search.  I fear that in time we will run into a wall and
iq:stats will not scale.

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.

A few days ago, I suggested that iq:rpc be used, but in thinking about it,
that might be major overkill.  So here is another suggestion, one that I hope
the authors will take seriously.

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.

Let's turn:

<iq type='get' to='foo'>
  <query xmlns='jabber:iq:stats'>
    <who/><uptime/><traffic/>
  </query>
</iq>

into the following:

<iq type='get' to='foo'>
  <query xmlns='jabber:iq:stats'>
    <stat id='who'/>
    <stat id='uptime'/>
    <stat id='traffic'/>
  </query>
</iq>


Now you can query a service and find out what stats they support:


Send:
<iq type='get' to='jud'>
  <query xmlns='jabber:iq:stats'/>
</iq>


Recv:
<iq type='result' from='jud'>
  <query xmlns='jabber:iq:stats'>
    <stat id='uptime'/>
    <stat id='num_users'/>
    <stat id='server_breakdown'/>
  </query>
</iq>


So the JUD was able to provide stats back to the requester without having to
define it's own namespace or root tags.

I know that sometimes the values that will get returned will not fit into the
<stat/> tag.  It's really designed to hold a string, and possibly some tags
depending on how generic we can make them.  But we can use namespaces to hold
data that doesn't fit into the iq:stats mold:  (Note, this is an example.)

Send:
<iq type='get' to='jud'>
  <query xmlns='jabber:iq:stats'>
    <stat id='uptime'/>
    <stat id='num_users'/>
    <stat id='server_breakdown'/>
  </query>
</iq>

Recv:
<iq type='result' from='jud'>
  <query xmlns='jabber:iq:stats'>
    <stat id='uptime'>5555</stat>
    <stat id='num_users'>3067</stat>
    <stat id='server_breakdown'>
      <servers xmlns='jud:server_breakdown'>
        <server jid='jabber.org' num_users='556'/>
        <server jid='jabber.com' num_users='128'/>
        <server jid='jabbet.at' num_users='56'/>
        ...
    </servers>
    </stat>
  </query>
</iq>


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
language.

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.






Peter Saint-Andre <stpeter at jabber.org> said:

> I've received a JEP regarding more robust statistics support for Jabber
> servers and components. You can read it here:
> 
> http://www.jabber.org/jeps/jep-0039.html
> 
> I'll update the webpage and source control with this JEP tomorrow.
> 
> Enjoy!
> 
> Peter
> 
> --
> Peter Saint-Andre
> Jabber Software Foundation
> http://www.jabber.org/people/stpeter.html
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 



-- 
Ryan Eatmon
reatmon at jabber.org







More information about the Standards mailing list