[Council] Votes from 2008-10-15

Dave Cridland dave at cridland.net
Wed Oct 22 09:47:41 CDT 2008


On Wed Oct 22 15:05:56 2008, Peter Saint-Andre wrote:
> > I note that the XMPP Registrar doesn't actually make the  
> registration
> > while the document is in Experimental state, and I'm mildly  
> concerned
> > that this can - in theory - lead to a state where two XEPs in
> > Experimental end up with the same namespace, which is a bit silly.
> 
> Correct, the namespaces are minted when the XEP is Experimental but  
> not
> registered until the XEP is Draft. Registering every namespace might
> clutter up the registry with namespaces that are not approved and  
> never
> will be, and that strikes me as a bad idea (in particular it might  
> cause
> confusion regarding which namespaces are approved and which are  
> not).
> 
> 
Well, I think no more so than the clutter of Experimental vs Draft  
XEPs, really. I'm not saying "show them by default in registry views".


> > In practise, I assume that we do actually track what namespaces  
> are used
> > by Experimental XEPs, so it seems sensible for the XMPP Registrar  
> to
> > make a note of these in the same way as any other used namespace.
> 
> All namespaces are checked for uniqueness before they are minted,  
> and
> that check includes XEPs in all states, not just Draft or Final.  
> Would
> you prefer to make that explicit?
> 
> 
Documenting the existing practise always seems like a good idea.

> > 4) There's a significant amount of small cleanup work here. It'd  
> be
> > useful to have these seperated out.
> 
> What format would you find useful? A more detailed changelog?

No, actually - on reflection, I'm just moaning, really.

If "minor changes" and suchlike got moved out of the way, it'd only  
come back to bite us when some minor slip had technical impact.

> Jack raised an issue about backwards-compatibility regarding the
> <error/> and <accuracy/> elements, and I sent a "poll" about this  
> to the
> jdev@ and standards@ lists. One solution would be to say that
> implementations shall support both <error/> (= offset in arc  
> minutes)
> and <accuracy/> (= offset in meters) for some period of time, i.e.,  
> to
> not immediately deprecate <error/>. But first we need to find out  
> if any
> implementations support <error/> (I have my doubts).
> 
> 
Not only whether they support it, but whether they support it  
intentionally interoperably and rely upon it. I suspect we're early  
enough to make this change, and any applications which actually use  
it are quite likely talking to other instances of themselves, or form  
some similarly homogenous network.


> > 7) I still think USer Mood is very silly, but ours not to reason  
> why. +1.
> 
> Well, your mood is always grumpy so I can see why you'd think the  
> idea
> of publishing mood changes is silly. ;-)
> 
> 
<offended/> ;-)

Actually, it's largely down to the bizarre, and sometimes worrying,  
choices of iconography in Gajim. I'm sure that "Aroused" uses an icon  
intended to depict "Unexpected Body Cavity Search", and most of them  
appear to depict various stages of "Constipated".


> > 8) I think this is approaching silliness, too, but +1.
> 
> If you ask me, activity is even more risible than mood. But I try  
> not to
> let me personal usage and biases interfere with publishing specs  
> that
> some parts of the community deem useful (unless the protocol would  
> cause
> positive harm).
> 
> 
In a lot of cases, I can see good uses for the Activity, although  
it'd be more use if PEP Activity states were tied into user defined  
rich presence states, and made available through a simple drop-down  
in the client. Knowing that someone's present, but eating, gives me  
useful cues to response time, etc.

As well as satisfying my noseyness.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


More information about the Council mailing list