Re: Web Apps -- requirements for installation and management

Hi Tim,

On Feb 8, 2011, at 19:24 , Tim Berners-Lee wrote:
> As the Web Apps is becoming a seriously valuable cross-platform computing platform,
> we need to standardize as quickly as possible a large amount of functionality
> which developers 

We're working on it. There are some "interesting" issues in the field though that can make the "as quickly as possible" part difficult. There are also some political/vision differences that slow consensus down.

> - Express trust in a source of of software
> - Install software from a trusted source or sources, recursively loading dependencies (like debian packaging etc)

Trusting a web application is tricky. The problem is essentially that code injection is so easy in a web context. I've put some notes up about this at http://berjon.com/blog/2011/02/harmful-trust.html. TLR has been educating people about the issue for a couple years. There are solutions, but they all involve trade-offs that we need to make.

> - Be able to allocate to an app:
> 	-- Program storage
> 	-- Data storage

The File System API and IndexedDB should help.

  http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
  http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html

If it's just about controlling how much can an app access it's largely an implementation issue (though communicating quotas back to the code is useful in some cases.

> 	-- Access to data common to several apps 

Common access to data can be hard. It might be simplest to support cross-app messaging and have one app responsible for maintaining access to the shared data store. We can build atop Web Messaging for that. It might, however, require headless apps, which is something that webOS has but to the best of my knowledge isn't supported elsewhere. For end users to run something they don't see requires some form of trust, which again is a difficult problem.

  http://dev.w3.org/html5/postmsg/

> 	-- Access to Private data
> 	-- Devices, location, camera, microphone, etc

That's what DAP is for:

  http://dev.w3.org/2009/dap/calendar/
  http://dev.w3.org/2009/dap/camera/
  http://dev.w3.org/2009/dap/camera/Overview-API.html
  http://dev.w3.org/2009/dap/contacts/
  http://dev.w3.org/2009/dap/messaging/
  http://dev.w3.org/2009/dap/system-info/

(And more to come)

> - Be able to see which apps are responsible for using
>  how much of the above resources, or specifically dominating 
>  the use of them.  (Eg GrandPerspective on Mac, but same for network bandwidth
> through my machine or my house)
> Good user interfaces for these things will be necessary
> to cope with apps (or libraries) using too much resource accidentally
> or maliciously.

That's an implementation issue.

> - Be able to group apps and associate them with tasks or types of activity
> so that I can see which things which I like to do will suffer if I reclaim

Ditto.

> - Be able to upgrade apps automatically or manually

Widgets have the Updates specification, AppCache can use HTTP for that.

There is friction when we try to take to web offline. Right now we have AppCache that's taken the problem from the browser end, where we essentially have cache on steroids that can give guarantees that an app works offline (it doesn't have to stay in the browser but it is managed by it) and sticks to classic web functionality and security — so this brings over browser baggage which has huge advantages but may be limiting for some use cases. Widgets have attacked this space from the app end, essentially integrating web stuff in an app framework. This also has issues, for instance widget resources are identified with widget: URIs, which removes a lot of potentially useful HTTP infrastructure. There have been proposals to give widgets an origin in HTTP space but none that have been very convincing (to me) so far. I think that it's likely that there's a meeting point for these two approaches that would produce something more powerful than either, but I'm not convinced that as a community we've done enough thinking to hit it yet. It's a very hot topic though, so I'd expect solutions to flourish in the coming year.

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 9 February 2011 11:18:36 UTC