Add IDL and initial Blink API for Background Sync

public/platform/modules/background_sync/WebSyncRegistration.h

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef WebSyncRegistration_h
 #define WebSyncRegistration_h
 
 #include "public/platform/WebPrivatePtr.h"
 #include "public/platform/WebString.h"
 
 namespace blink {
 
-struct WebSyncRegistrationOptions {
+struct WebSyncRegistration {
     enum NetworkType {
         NetworkTypeAny = 0,
         NetworkTypeOffline,
         NetworkTypeOnline,
         NetworkTypeNonMobile,
         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