MozillaWiki

WebAPI/ProposedDeviceStorageAPIWithNotifications: Difference between revisions

Page Discussion

WebAPI/ProposedDeviceStorageAPIWithNotifications (view source)

Revision as of 23:54, 1 October 2014

1,322 bytes removed ,  1 October 2014
no edit summary
No edit summary
 
(15 intermediate revisions by one other user not shown)
Line 19: Line 19:
  };
  };
   
   
  interface DeviceStorage {
  interface DeviceStorage : EventTarget {
   // Name will be generated by the implementation and returned as result of request
   // Name will be generated by the implementation and returned as result of request
   DOMRequest add(Blob blob);
   DOMRequest add(Blob blob);
Line 35: Line 35:
   DOMRequest delete(DOMString name);
   DOMRequest delete(DOMString name);
   
   
   // Watches a file for updates
   // Adds a listener for a file update event.
   // returns the DeviceStorageWatch for this request, through which future requests will be processed
  // The type determines what type of event to listen for: one of "created","deleted", and "modified".
   DeviceStorageWatch watchFileChange(DOMString name);
   // The listener recieves notification when an event occurs
  // If true, useCapture indicates that the user wishes to initiate capture. After initiating capture, all events of the specified type will be dispatched to the registered listener before being dispatched to any EventTarget beneath it in the DOM tree.
   void addEventListener(DOMString type, EventListener listener, optional boolean useCapture);
   
   
   // Watches all files for updates
   // Removes the listener for the given file update event
   // returns the DeviceStorageWatch for this request, through which future requests will be processed
   // the listener will stop receiving notifications after this call.
   DeviceStorageWatch watchChanges();
  void removeEventListener(DOMString type, EventListener listener);
  // Sends an event to the event listeners the same as if it was delivered directly.
   boolean dispatchEvent(DeviceStorageChangeEvent event);
   
   
   // See interface below for how to use this
   // See interface below for how to use this
Line 54: Line 59:
  };
  };
   
   
  interface DeviceStorageWatch{
  interface DeviceStorageChangeEvent : Event{
   // this function is called whenever the file(s) addressed by the request are created, modified, or deleted
   //.type is "devicestoragechange"
   void onChange(DOMString name, UpdateType type);
  //.target is the DeviceStorage object that caused this
  // this function is called whenever the file(s) addressed by the request are renamed
  DOMString change; //one of "created","modified", or "deleted"
  void onRename(DOMSring oldName, DOMString newName);
   DOMString path; //absolute path to the file that updated
  // this function stops the watcher permanently
  void cancel();
  }
  }


The cursor API is somewhat different from the IndexedDB cursor in that it's a bit simpler. We might want to align more with IndexedDB just for the sake of consistency.
[[Category:Web APIs]]
 
== Questions ==
 
* Q: Why not use the [http://www.w3.org/TR/file-system-api/ W3C File System] API?  This API seems somewhat redundant with that part of the web platform.
 
== Security/Privacy considerations ==
 
There are basically three different capabilities here:
* Ability to add new files. This can't cause any harm in and of itself apart from using system resources.
* Ability to read existing files. This isn't a security problem, but is a privacy problem.
* Ability to modify/delete existing files. This can destroy user data.
 
Ability to add new files isn't terribly sensitive, simply asking the user might be sufficient here.
 
Ability to read existing files is more sensitive. Note that we should integrate device storage with <input type=file> such that the user is able to select a file from device storage on all platforms. That should significantly reduce the need for pages to use this API.
 
We could possibly further reduce the need by granting pages/apps the right to read files that they have added. I.e. only when wanting to read other files would we need to apply security restrictions. Implementing this on desktop will be hard though since we would have to keep additional meta-data on files that are stored in the user's "pictures", etc folders. I'm inclined to defer this aspect for now.
 
Ability to modify/delete existing files is extremely sensitive. We likely wouldn't want a scenario where the user simply answers yes to a "Do you want to let this website modify your pictures folder" and then have all of their vacation photos from the past 10 years destroyed.
Chaasof
Confirmed users
1,340

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/433438...1021392"