[standards-jig] jep-0039 (Statistics Gathering)

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Sat Nov 9 19:26:17 UTC 2002


Responses in-line...

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,
though.

>     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
> http://mailman.jabber.org/listinfo/standards-jig
-- 
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 mailing list