Add IDL and initial Blink API for Background Sync

public/platform/modules/background_sync/WebSyncRegistration.h

Index: public/platform/modules/background_sync/WebSyncRegistration.h
diff --git a/public/platform/modules/background_sync/WebSyncRegistration.h b/public/platform/modules/background_sync/WebSyncRegistration.h
index cd9cdc20013d995560e2105f8801a593c0b844d8..54195194c463cecb3194ad9c7dd3a5c872d76e44 100644
--- a/public/platform/modules/background_sync/WebSyncRegistration.h
+++ b/public/platform/modules/background_sync/WebSyncRegistration.h
@@ -10,7 +10,7 @@
 
 namespace blink {
 
-struct WebSyncRegistrationOptions {
+struct WebSyncRegistration {
     enum NetworkType {
         NetworkTypeAny = 0,
         NetworkTypeOffline,
@@ -19,30 +19,28 @@ struct WebSyncRegistrationOptions {
         NetworkTypeLast = NetworkTypeNonMobile
     };
 
-    WebSyncRegistrationOptions(NetworkType networkType, bool allowOnBattery, bool idleRequired)
-        : networkType(networkType)
+    WebSyncRegistration(const WebString& registrationId, unsigned long minDelay,
+        unsigned long maxDelay, unsigned long minPeriod, NetworkType minRequiredNetwork,

[jochen (gone - plz use gerrit), 2015/03/17 12:25:35]

even if the idl doesn't have units, I think we should have units on internal
variable names.

[iclelland, 2015/03/19 13:13:43]

I'll add this as "millis" (By analogy with Java's getCurrentTimeMillis() call).
Is that an appropriate suffix, or should it be "milliseconds", "ms", or (the
camelCaseMegaSecond) "Ms"?

+        bool allowOnBattery, bool idleRequired)
+        : id(registrationId)
+        , minDelay(minDelay)
+        , maxDelay(maxDelay)
+        , minPeriod(minPeriod)
+        , minRequiredNetwork(minRequiredNetwork)
         , allowOnBattery(allowOnBattery)
         , idleRequired(idleRequired)
     {

[jochen (gone - plz use gerrit), 2015/03/17 12:25:35]

what about adding an assert that minDelay <= maxDelay or whatever the actual
constraint is?

[iclelland, 2015/03/19 13:13:43]

I suppose the actual constraint would be
(minDelay <= maxDelay) || (maxDelay == 0)

if there was to be one. Neither of these parameters are hard requirements for
the browser to obey. When passed in from a register() call, they represent the
web site's request (which may not be honoured), and when passed back to blink
from the browser, they would just represent the values which have been stored,
possibly after modification by the user or the browser (and still don't mean
that the browser promises to obey them).

Does the assert make sense in the context of a struct constructor? Without being
a class with private data members, it doesn't actually enforce anything. I can
easily assert in the syncManager.register() call, and reject if the constraint
is violated.

     }
 
-    NetworkType networkType;
+    WebString id;
+    unsigned long minDelay;
+    unsigned long maxDelay;
+    unsigned long minPeriod;
+    NetworkType minRequiredNetwork;
     bool allowOnBattery;
     bool idleRequired;
 };
 
-
-struct WebSyncRegistration {
-    WebSyncRegistration(const WebString& registrationId, const WebSyncRegistrationOptions& options)
-        : id(registrationId)
-        , options(options)
-    {
-    }
-
-    WebString id;
-    WebSyncRegistrationOptions options;
-};
-
 } // namespace blink
 
 #endif // WebSyncRegistration_h