[standards-jig] jep-0039 (Statistics Gathering)
Matthew A. Miller
linuxwolf at outer-planes.no-ip.com
Sat Nov 9 19:26:17 UTC 2002
On Fri, 2002-11-08 at 22:22, Russell Davis wrote:
> i've been rereading the jep and come the the conclusion it is currently
> extremly limited in it's usefulness.
> 1. It is currently documented as a pull only namespace, however
> there are circumstances when it would be nice if it were possible to
> "subscribe" to a statistic and have it pushed to us every X seconds.
> Should this be handled via pub/sub or should it be part of this jep?
Lacking an actual pub/sub standard, allowing [in the spec] for <query
xmlns='http://jabber.org/protocol/stats'/> to be placed within anything
that accepts extensions could work. This way, someone could push stats
using <message/> or (*shudder*) <presence/>. Also, this could allow for
other extensions to embed stats, letting us poor software developers
reuse more of our code! (-:
I would also recommend that the actions to subscribe/unsubscribe to this
"push" be an implementation detail (for now). There are various
mechanisms available that could be used; "jabber:iq:register" or
x-commands/x:data being just two I can think of right now.
What I think is the greatest benefit of the is the amount of reuse it
allows. For now, it means that stats can arrive when asked for (<iq/>)
or when "not asked for" (<message/>). When a true pub/sub spec is
finalized, I think there would be very few changes, if any.
> 2. The format of the name attribute limits it's usefulness and
> flexibilty. In particular in might be desirable to take the a query to
> a third level or deeper i.e. rather than just bandwidth/packets-in i
> might want to split the packets-in into their particular type i.e.
> <iq/>, <message/>, <presence/> or even further. Should this be handled
> by using JANA to just create multiple ways of obtaining the same
> statistic i.e. bandwidth/packets-in and packets/iq, packets/presence...
> or should the name attribute extend to three or more levels i.e.
> bandwidth/packets-in#iq, bandwidth/packets-in#presence... (or some
> variation of this)
It's probably better to leave the names up to JANA. JEP-0039 should
recommend a structure that JANA could use for stats name criteria,
> 3. Perhaps there should be one type of non-numeric statistic to
> allow queries such as last logged in jid, this would not be a list just
> a simple string.?
Looking over JEP-0039, I see there's a "units" attribute. Most units
would be numeric, but I don't see any reason for not specifying a couple
of non-numeric units:
units='jid': This is for a JID
units='date': This is for a date/time (ISO-8601 format)
Further, it would end up being the responsibility of JEP-0039/JANA to
decide what "datatype" each unit is. And even further, these are just
strings. If the receiver doesn't know what to do with the value, just
treat it as a string!
> all of the above complicate the implementation to varying degrees so
> comments and suggestions please.
> bst rgrds
> Russell Davis
> jid: ukscone at burninghorse.com
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Matt "linuxwolf" Miller
E-MAIL: linuxwolf at outer-planes.net
JID: linuxwolf at outer-planes.net
- Get JABBER! (http://www.jabber.org/)
More information about the Standards