On 8.2.2012 14:25, Scott Wilson wrote:
Hi
just let me quote from this thread
-------------------------------------------------
Tim Berners-Lee:
There of course places where XHR is used and there is no
cross-sitescripting security needed
1) in a browser extension
2) in node.js code trusted apps
Ian Hickson:
These aren't the Web, so they're probably out of scope of the CORS and XHR
specs, but Anne can comment if he disagrees.
-------------------------------------------------
you are one step ahead, firt we need to define, what we want, whether we want
web platform (remote access to some data and sometimes being able to manipulate
those data with very limited set of APIs) or whether we want actual
multi-platform application framework with browser as run-time environment,
because there is still a lot of missing and there is apparently disagreement
about what should be govern by w3c/whatwg. I'm all for the second option: full
programming environment. But that is the first here (and with MS extensions to
JS APIs in Metro applications...). And without any distinction between whether
the app run locally or whether the UI and data are accessed remotely or any
possible combination of UI and data access mechanism.
And the question of granting rights seems to be fairly decided here, everything
potentially dangerous has to be granted by user (e.g. FileSystem API, GeoLocation), and
if UA can provide more granular way of managing data and rights (not "remove
browsing data" and suddenly everything for every page is gone), we can stick with
this principle: HTML, CSS, basic JS is fine... anything else must be granted.
Right, and so far we haven't had a generic model for how that is done, instead
individual specs have had to define it (as in your examples).
WebIntents potentially offers a generic model for apps requesting data while
keeping the user in the loop, and one that would work both for websites/hosted
apps/normal apps and widgets/installed apps/system apps.
Hi,
WebIntents rather not... Those are about registering services to perform
some common tasks. That is fine for clearly defined data and actions
(and shared communication among two full fully-fledged application)...
but way to high level. It takes time to put low level functionality
together to make things work, but you can do a lot... (and there are
always libraries for most common tasks). But with high level APIs? no
way to bend those.
I ment something like
constructor FileAccess(String path)
onstartload(event)
onendload(event with cause of end (success or some error) and Blob
object )
onprogress(event)
read()
write()
where path in constructor can be HTTP address, FTP address, local
address (c:\path\myfile.txt)
of course based on privileges on local side, on server side (based on
used address)
but as low level as possible and as generic as possible (exactly the
same functionality locally, remotely).
But we have strayed away a little bit :)
B.
