Re: [Standards] Push notification XEP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So do I! I'm eager for seeing this move forward and start making experimental/reference implementations. You can count on a strophe client plugin and prosody server one ;) Regards, - -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS7lNQAAoJEOKCghY7/+mkvaEIAJ6REShFrifFBhOcAMaoTpLq msau0/fUXo8Py3XXwmR1D0lcWc/IaaPPjqyooc/SYf4UHUaADj8FR4UX6VFDnN0B /YzamgM7//p+8DJsSJ1zga58qlJmiFEn0xFsPNZdvgawKtfE1wlRgn+ztwdQnWGf 1cLJ5leunUToEmXNWnvZOZ6M+/NUahsVpccbiv9r8dBBtV2hN5bYm3UwsTwmWUtU kT1rln3gzXVWmFVIpAUyHLCQqujPZ0w0dwdv006pPX4IQCwKUyn8e+gel7bTZB4/ hF6Hovnxa/3FA1okE823HWjAk+V8xbHT+z+lkqqiXs5tRH9Ht41P5pqKj0D6dq0= =AXuq -END PGP SIGNATURE-
Re: [Standards] Push notification XEP
> My server, lance.im, never needs to know anything about iOS or GCM or anything > specific to my phone. It has no 'provider ID'; my server never talks to Apple, > Google, etc. Very smart solution, otherwise we would have to support an endless list of PUSH services (Apple, Google, RIM, etc.) Lance, I've read your XEP draft and sounds to me like a very good point to start from. My doubt is: what kind of information may the payload carry given that it's generated by the user's server? Any use case for that? Thanks. Regards, -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com
Re: [Standards] Push notification XEP
Hi everyone, Another different PUSH service to take into account just to illustrate how much some PUSH services differ from others: the upcoming Javascript Push API (W3C Working Draft [1]). In this WebAPI there is no such thing as device tokens or registration IDs, nor API keys or sender IDs. You just ask the PUSH server for a new endpoint with PushManager.register(); and it returns an URI like this: https://as.push.tefdigital.com/v1/notify/abcdef01234567890abcdefabcdef01234567890abcdef Then you need to pass the endpoint to the server and every time you perform a HTTP PUSH with incremental attribute "version", your webapp receives a "push" event. [1] https://dvcs.w3.org/hg/push/raw-file/default/index.html Regards, -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com
Re: [Standards] LAST CALL: XEP-0152 (Reachability Addresses)
Hello everyone, Don't you think this XEP could be very convenient for providing your server a PUSH endpoint URI to be HTTP-PUTted upon new messages while show is away or xa? Of course this would lead us to the eternal discussion on what kind of stanzas should be forwarded / queued. (See the "Standard for Throttling/Queueing Stanzas" thread in this same mail list). What do you reckon? Is there a most elegant way to do so? What's more, are there any plans for drawing a XEP on interoperation with PUSH technologies? XMPP is no longer only in desktops but in smartphones and sensors, you already know ;) Regards, -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com
Re: [Standards] Standard for Throttling/Queueing Stanzas
Hello everyone, > Other solutions can be envisioned, for instance using presence=away > to signal clients restricting them to send important messages only, > queuing not as important messages for later when online, etc. That's exactly what Loqui IM for Firefox OS does. When the app goes to background or the phone is locked, the "show" is changed to "away" and the server stops sending it presence stanzas. It's not elegant at all, but fits the purpose of saving battery and keeping the app from being killed by the system. Do you know of any other better way to implement this? Shouldn't we have a standard method to tell a server that it should send a client important messages only? Regards, -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com
[Standards] When is it ok to query for CSN support?
Hello everyone, I hope this is the proper mailing list for asking about standards implementation. If not, please tell me where to reach instead. I'm currently developing Loqui, a open source XMPP client app for FirefoxOS and the web. It formerly supported Chat State Notifications, but determined support by using the "business rules" in XEP-0085 5.1 Nevertheless, the XEP stands that the preferred way to determine support for CSN is by using 'Service Discovery' or 'Entity Capabilities' extensions. So my question is: When is it ok to perform that disco/caps queries? Should I query everyone in my roster upon logged in? Or should I query just one user once I open a chat window? How long may I cache the result of the query? What's more: though not said in XEP-0085, I think CSN support is clearly resource-based. Should I query every available resource from a user and then obey the one with the highest priority value? Maybe those were too many questions... so thanks in advance :) -- *Adán Sánchez de Pedro Crespo* /FLOSS Developer at Waaltcom/ PGP Public Key: CCABF8A0 Cel.: +34 663 163 375 Fix.: +34 912 69 22 00 PLN: +00 4200 VoIP: 2...@sip.waalt.com
