- From: <richard.tibbett@orange-ftgroup.com>
- Date: Tue, 2 Mar 2010 12:29:05 +0100
- To: <public-device-apis@w3.org>, <mseaborn@chromium.org>
On Sun, 28 Feb 2010 at 19:45, Mark Seaborn <mseaborn@chromium.org> wrote: > > If the browser were responsible for aggregating > responses like this it would need to know about the protocols > and data formats supported by particular resource types. > This is something we specifically want to avoid in the > Powerbox proposal. The Powerbox just provides a generic > facility for introducing a customer web app to a resource by > passing a URL (and, for the sake of compatibility with file > upload, a blob of data) to the customer. We don't want the > Powerbox to need to know how to interpret this data. > I would say that we do want a Powerbox to know how to interpret the data being sent and received for a finite set of API use cases. Being data-aware provides more granular filtering, parameterization, richer opt-in/review interfaces and better security and privacy controls - IMO all of the challenges of this working group. It should be possible for a webapp to request specific sets of an object's attributes and to receive only those requested attributes in response - and allow all that to happen in a consistent way across Provider implementors. It should do all that without unneccessarily exposing a whole Blob/File object when only a slice of that object will do - and if only a slice will do then why not sufficiently structure that slice of data so its individual components can be used at runtime by the developer in their webapp? So I question whether returning File-like objects to an input elements 'value' attribute is going to cut it for all DAP API use cases. - Richard ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************
Received on Tuesday, 2 March 2010 11:35:03 UTC