2009/9/19 Peter Saint-Andre <stpe...@stpeter.im>: > -----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 :) >> * 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? >> * 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. >> * 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. >> * 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 :) Matthew
