-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/19/09 4:47 AM, Matthew Wild wrote: > 2009/9/19 Peter Saint-Andre <[email protected]>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/18/09 8:31 PM, Peter Saint-Andre wrote: >>> As copied from the Radar page... >>> >>> Experimental XEPs are automatically deferred after 12 months of >>> inactivity. The following XEPs are set to be automatically deferred >>> within the next ~30 days. >>> >>> * XEP-0181: Jingle DTMF >> I'd like to see that one move forward, but I'll poke Sean Egan about it >> to see what the thinks. >> > > Not being a client/Jingle developer, yes, I'll leave it to someone > else to decide on the usefulness of this XEP. It sure /looks/ useful > :)
IIRC, Robert McQueen thought that we could define this but then advance the spec when someone is actually using it. >>> * XEP-0194: User Chatting > > I've heard people (perhaps it was the Gajim crowd?) planning to > implement this, let's see how it goes. > >>> * XEP-0195: User Browsing >>> * XEP-0196: User Gaming >>> * XEP-0197: User Viewing > > These are all things which aren't used right now (as far as I know) > but still something that should be standardised when they are (I'm > sure at least User Browsing will be). > > Perhaps it is better to let them drop now though, and revive if/when > necessary? Agreed. We'll keep them in our back pocket. >>> * XEP-0168: Resource Application Priority > > Did anyone end up implementing this? It seems another stab at trying > to rid us of negative priorities, which still seems to have a > dedicated following :) > >>> * XEP-0152: Reachability Addresses > > I think this is best addressed by an updated user profile (not > necessarily User Profile) XEP. I think we can let those two lapse. >>> * XEP-0225: Component Connections >> IMHO it would be great to work on this, although Jack Moffitt has >> questioned how useful any kind of external component protocol really is >> (given that you serializing and deserializing XML is expensive). >> > > +1 to keeping this alive, it's something I'm quite interested in. > Regardless of efficiency, components are very popular, they are a > great way to implement services, and can be load-balanced, etc. We > should definitely keep the ball rolling in this area. > > Regarding efficiency, by using a more "standard" XMPP stream, it would > allow components to negotiate compression, or other more efficient > encodings of the stream such as XEP-0239. I would love to see some further progress in this area. >>> * XEP-0186: Invisible Command >> I don't like invisibility in general, but if we're going to have it then >> I'd at least like to do so in an intelligent way. Perhaps XEP-0186 is it. >> > > Yes, I think it is (I'm also interested in solving invisibility to an > extent). It's a mess right now, but I'll re-read the XEPs some time > and see which one I would rather implement and improve :) I must admit that I can't get all excited about invisibility... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkq027wACgkQNL8k5A2w/vyaDQCg59QVlPUwqd/Fgm8Ji97qoCQe /7AAn3cdNK7aZWGE3WVm7PaZlUwsZnAB =C6rg -----END PGP SIGNATURE-----
