MozillaWiki

WebAPI/SimplePush: Difference between revisions

Page Discussion

WebAPI/SimplePush (view source)

Revision as of 18:23, 31 January 2013

2,501 bytes added ,  31 January 2013
→‎Messy Details
Line 37: Line 37:
== Use Cases ==
== Use Cases ==


== Messy Details ==
<p>You're a service. Getting clients to talk to you is pretty easy. All you have to do is sit there and wait for them to call. But, what if you want to tell your clients that there's something interesting for them?
 
</p><p>SimplePush is a very low cost service that let's servers tell clients "Hey, there's something interesting over here! You ought to do something about that."
=== Client Side API ===
</p>
<h2> Definitions </h2>
<p>Before we get into details, it's important that we have a good lexicon.
</p>
<dl><dt>App
</dt><dd>The remote receiver of the SimplePush Notification.<br />The app is what requests things get established, gets pinged when something interesting happens, and connects back to the AppServer.
</dd></dl>
<dl><dt>AppServer
</dt><dd>The third party publisher of update notices.<br />This is, more than likely, where all the real work of your App is done. It's what has the mail, or the articles, or where someone whacks serpents with farm implements for slices of virtual dessert.
</dd></dl>
<dl><dt>UserAgent
</dt><dd>The client acting on behalf of the user and consumer of update notices<br />This is what handles talking back to the PushServer and wakes up the App when there's something of interest. For example: Firefox Desktop, Firefox OS (a service runs in the background)
</dd></dl>
<dl><dt>PushServer
</dt><dd>The server managing interactions between AppServers and the UserAgent.<br />This is what the AppServer is talking to when it wants to tickle the client.
</dd></dl>
<dl><dt>Endpoint
</dt><dd>Unique URL to be used by the AppServer to initiate a response from the App.<br />This is generated by SimplePush and sent to the App. The App will need to relay this to the AppServer.
</dd></dl>
<p>The following are SimplePush hoo-doo things that are probably not important to you. Here, look at this device while I put on my sunglasses.
</p>
<dl><dt>Channel
</dt><dd>The flow of information from AppServer through PushServer to UserAgent.
</dd></dl>
<dl><dt>ChannelID
</dt><dd>Unique identifier for a Channel. Generated by UserAgent for a particular application.
</dd></dl>
<dl><dt>UAID
</dt><dd>A globally unique UserAgent ID
</dd></dl>
<p><br />
UserAgent and AppServer will use a RESTful API to interact with the Push Server.
</p>
<h2> Use Cases </h2>
<h2> Messy Details </h2>
<h3> Client Side API </h3>
<pre>
<pre>


Line 71: Line 106:
};
};


interface PushEvent : Event {
interface PushEvent&#160;: Event {
   PushRegistration target;
   PushRegistration target;
}
}


</pre>
</pre>
 
<h3> Client Example </h3>
=== Client Example ===
<h4> App manifest </h4>
 
==== App manifest ====
<pre>
<pre>


{
{
   ...
   ...
   "messages": [
   &quot;messages&quot;: [
     {"push": "/view_to_launch.html"}
     {&quot;push&quot;: &quot;/view_to_launch.html&quot;}
     {"push-register": "/view_to_launch.html"}
     {&quot;push-register&quot;: &quot;/view_to_launch.html&quot;}
   ]
   ]
}
}


</pre>
</pre>
 
<h4> JavaScript </h4>
==== JavaScript ====
<pre>
<pre>


Line 104: Line 136:
   reqEmail.onsuccess = function(e) {
   reqEmail.onsuccess = function(e) {
     emailEndpoint = e.result.pushEndpoint;
     emailEndpoint = e.result.pushEndpoint;
     storeOnAppServer("email", emailEndpoint);
     storeOnAppServer(&quot;email&quot;, emailEndpoint);
   }
   }


Line 110: Line 142:
   reqIm.onsuccess = function(e) {
   reqIm.onsuccess = function(e) {
     imEndpoint = e.result.pushEndpoint;
     imEndpoint = e.result.pushEndpoint;
     storeOnAppServer("im", imEndpoint);
     storeOnAppServer(&quot;im&quot;, imEndpoint);
   }
   }
}
}
Line 151: Line 183:


</pre>
</pre>
 
<h4> Notes </h4>
==== Notes ====
<p>The current spec works for apps. Ideally it should work for web pages loaded in browsers as well.
 
The current spec works for apps. Ideally it should work for web pages loaded in browsers as well.
Current issues blocking this:
Current issues blocking this:
* mozSetMessageHandler indexes by app manifest. Web pages don't have app manifests.
</p>
* The lifetime of registrations for web pages needs specification.
<ul><li> mozSetMessageHandler indexes by app manifest. Web pages don't have app manifests.
* Every instance of a web page should be treated differently. So the same URL in two tabs should have different channels (and ask permission?). Again geolocation, desktop-notification and others may provide clues)
</li><li> The lifetime of registrations for web pages needs specification.
* In the case of the b2g browser, the browser is an app and so mozSetMessageHandler gets its manifest, and not access to the pages. We might want to bypass the browser and plug directly into the mozbrowseriframe of each tab. Again within each tab, user might navigate away from page, which may need invalidation.
</li><li> Every instance of a web page should be treated differently. So the same URL in two tabs should have different channels (and ask permission?). Again geolocation, desktop-notification and others may provide clues)
 
</li><li> In the case of the b2g browser, the browser is an app and so mozSetMessageHandler gets its manifest, and not access to the pages. We might want to bypass the browser and plug directly into the mozbrowseriframe of each tab. Again within each tab, user might navigate away from page, which may need invalidation.
==== UI ====
</li></ul>
* During app installation, the user agent should notify the user that the app uses push notifications, and possibly deny permission.
<h4> UI </h4>
* Web pages using push notification should show a doorhangar notification in the same way (look at geolocation to see how this is done).
<ul><li> During app installation, the user agent should notify the user that the app uses push notifications, and possibly deny permission.
 
</li><li> Web pages using push notification should show a doorhangar notification in the same way (look at geolocation to see how this is done).
=== Server API ===
</li></ul>
[[/ServerAPI|ServerAPI]] has the details of how the ServerAPI works.  
<h3> Server API </h3>
 
<p><a href="/ServerAPI">ServerAPI</a> has the details of how the ServerAPI works.  
Chances are, all you want is to send a new version update.
</p><p>Chances are, all you want is to send a new version update.
 
</p><p>The simplest way to do that is to call
The simplest way to do that is to call
</p>
 
<pre class="_fck_mw_lspace">POST <i>endpoint</i>
POST <i>endpoint</i>
version=<i>newversion</i>
version=<i>newversion</i>
</pre>
 
<p>Where <i>endpoint</i> is the value that was returned during App's registration.
Where <i>endpoint</i> is the value that was returned during App's registration.
</p>
Jrconlin
Confirmed users
1,021

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/510223"