WebAPI/SettingsAPI: Difference between revisions

WebAPI/SettingsAPI (view source)

Revision as of 14:02, 22 November 2011

58 bytes added , 22 November 2011

improving the proposal

Mounir.lamouri

Confirmed users

368

edits

@@ Line 12: / Line 12: @@
      const DOMString FOOBAR = "foobar";
-     // Setters. SettingsRequest.result is always null.
+     // SettingsRequest.result contains the new value of the setting.
      SettingsRequest set(DOMString name, DOMString value);
-    SettingsRequest set(DOMString name, long value);
-    SettingsRequest set(DOMString name, long long value);
-    SettingsRequest set(DOMString name, float value);
-     // Getters. SettingsRequest.result will be of the requested type if the success event is sent.
+     // SettingsRequest.result contains the value of the setting.
-     SettingsRequest getString(DOMString name);
+     SettingsRequest get(DOMString name);
-     SettingsRequest getInt(DOMString name);
+  }
-     SettingsRequest getLong(DOMString name);
-     SettingsRequest getFloat(DOMString name);
+  /* Similar to SmsRequest. */
+  interface SettingsRequest
+  {
+     readonly attribute DOMString readyState; // "processing" or "done"
+    readonly attribute DOMError? error;
+    attribute EventListener      onsuccess;
+    attribute EventListener      onerror;
+    attribute readonly any?      result;
+  };
+  [Constructor(DOMString type, optional SettingsEventInit settingsEventInitDict)]
+  interface SettingsEvent : Event
+  {
+    readonly attribute DOMString settingName;
+     readonly attribute DOMString settingValue;
+  };
+  dictionary SettingsEventInit : EventInit {
+    DOMString settingName;
+     DOMString settingValue;
    }
@@ Line 28: / Line 44: @@
 * SettingsRequest will be similar to SMSRequest described in [[WebAPI/WebSMS|WebSMS specification]].
-* As for BatteryAPI, SettingsManager object might be in window.navigator, window.navigator.devices or even could be created with ''new''.
+* If a setting is unknown by the platform, it should fail.
-* The allowed types are restricted to the type we know we will be using in the first implementation. Those could be extended.
-* If a setting is unknown, it should fail.
 * But some platforms might not know some settings. Do we want to add a method that checks if the platform knows a specific setting?