Re: [Widgets] R21. Resource Declarations. Was RE: Request for Comments on Widgets 1.0 Requirements Last Call WD

Hi Bryan,
On Thu, Sep 4, 2008 at 12:06 AM, Sullivan, Bryan <BS3131@att.com> wrote:
> Hi Marcos,
> My response is late (the review happened just before vacation and other things...), but here it is:
>
> I'm not sure there is a semantically useful way to declare/assess resource dependencies (currently), but that would be the goal. In the meantime simple disclosure is better than the "use it if it works for you, otherwise get rid of it" approach. At least the user may be able to understand the significance of the disclosure.
>
> The examples I provided in the proposal illustrate common resource constraint cases:
>
> a) automated operation
>
> a.1) network-intensive applications can cost users a lot of money (a critical resource) or drain the device battery (another critical resource). Applications that are designed to operate all the time or in the background (e.g. using Ajax methods) should disclose this so that the user can decide if that's what they want to allow. If possible, the extent of resource usage (frequency of network requests, typical amount of data exchanged) should be disclosed.
>
I fully understand that problem but this depends on the author being
honest and making an informed subjective judgment on resource
use/abuse of a widget. If I was an author, and I knew that this might
mean that some people won't use my app, then I would not include such
declarations. In other words, this system is too open to abuse/neglect
as the author can simply lie and say that their widget is awesome and
perfect (same problem that is seen with CC/PP: I can simply lie, and
I'm sure many sites do and there is no legal consequence to lying). My
position is that it should be up to the widget user agent to inform
the user that a Widget is using up too many resources.

I hate to subscribe to technological determinism but, another factor
is phones in two years may, for example, come with 20 processors and a
built in solar-nuclear-thermal-battery-reactor(tm) and carriers will
give everyone unlimited download/bandwidth, so things that are
considered "resource intensive" today, will mean very little tomorrow
or ten years from now.

> a.2) screen updates (e.g. for phonetop widgets) and memory updates (e.g. managing content and variables) can be battery-affecting. Application designers should have some understanding of the typical effect that their applications will have on the devices they target, and make at least useful disclosures of such effects.
>

Again, I still think that this should be handled by widget user agents
for the reasons above.

> b) storage requirements: Web applications may manage local persistent (e.g. flash) storage of content related to the application, and may have a significant impact on the operating memory (e.g. ram) of the device. While user choice in use of the application may significantly affect the storage requirements, the developer should have some understanding of the typical storage requirements. The user could then decide based upon the disclosure, whether they want to allocate a potentially significant amount of storage to this application.
>

The Widget 1.0 Updates specification defines an element that allows
the user to be informed of the size of the update they are about to
install. Also, a widget user agent could make a HEAD request to a
server prior to downloading a widget package to determine its size...
though I can see this doesn't exactly cover your use case. Regardless,
I still see this as an implementation detail.

> The real goal as I mentioned would be that a policy management engine could use the declarations to determine if the application would exceed a certain policy (which the user could manage as preferences). Semantic assessment of impact would resolve the variable "relative" impact problem (or at least reduce it), since the assessor would know how to relate the resource declarations in the context of the host device.
>

I agree, and some limited provisions are in place. But I still think
the model is fundamentally flawed if it depends on the author being
honest.

> In the meantime however at least some schema-defined disclosure of resource impacts could be used in a widget installer UI to inform the user of the impacts that the developer is aware of.
>

I think such things are best left to be described by publishers and
the end-user community. I.e., publishers already make it possible for
users of widgets to leave comments on websites that describe if a
widget sucks, uses too many resources, is slow on some particular
device, etc... By looking at a typical software download site, I think
its pretty clear that users make judgments about whether they download
a applications based on an application's popularity and the comments
left by others... or from other trusted systems of recommendation
(e.g. a friend tells you that an app is really useful)... except for
the poor souls who are tricked into downloading spy/malware, which the
technical solutions that are being proposed don't address.

I think a better approach to all the problems you list would be to
allow such declarations to be managed independently of the widget
package (and hence the author), so that device capability information
can be dynamically updated remotely as technology progresses or
regresses (e.g. in a last ditch effort to curve global warming, a
global agreement is reached  that requires devices to be more
environmentally friendly at the expense of performance and battery
life... etc.). Such a system could be managed by an external trusted
community, such as the community that contributes to, and gets widgets
from, a widget download website. The technological infrastructure
needed to develop such a thing is beyond the scope of Widgets 1.0 (but
that's not to say that it should not be part of any Widgets 2.0
effort).

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 4 September 2008 23:02:16 UTC