RE: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Friday, June 11, 2010 3:20 PM So there is a real likelyhood of a browser implementation that will predate it's associated JS engine's upgrade to ES5? Feeling a concern isn't really much of technical argument on it's own, and designing for outdated technology is a poor approach. I don't think there is, just wanted to avoid imposing it. If you think it's really important then let's change it back to delete assuming other folks are good with it. I had the same concerns Pablo did, but I don't feel strongly either way. Besides the maneuvering we'll have to do on the C++ side of things to avoid clashes with language keywords, the question is whether we expect plugins and such to add support for IndexedDB in existing browsers that don't do ES5. For example: http://code.google.com/p/firebreath/wiki/FireBreathUsers Before we close on this, let me validate one more thing independently of the JS version. Are we going to have trouble when trying to expose these interfaces in C++? Not sure about other compilers and IDL processing tools, but I'm playing around with Visual Studio 2010 and while the COM IDL compiler will take delete as an interface member, my C++ compiler really doesn't like it. As far as I know there is no standard syntax to indicate that a symbol wasn't meant to be a keyword in C++, so having delete (or other C++ keywords for that matter) would be problematic. Am I missing something? Good point. Does anyone have a strong opinion on how much we should care about reserved word conflicts in language other than JavaScript? it seems like a slippery slope. As an example, IDBDatabase.description is actually used by the ObjectiveC base object class and so this caused some problems initially. We worked around it by having the ObjectiveC bindings generator add a suffix whenever an attribute named description is hit. (Something similar was done for hash and id in other APIs.) To be honest, I hadn't even considered bringing this up and asking for it to be changed, but if we're going to avoid delete because it's a reserved word in JavaScript (pre v5) and/or because it's a reserved word in C++, perhaps we should consider changing description as well? We've had to do this a few times in the past already. One example was Window.postMessage where we couldn't use the name PostMessage in C++ because it was a predefined macro on some platform (windows iirc, not to point fingers ;) ). :) We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that. -pablo
Re: [cors] Simplify CORS Headers (ISSUE-89)
On Fri, 07 May 2010 02:30:10 +0200, Anne van Kesteren ann...@opera.com wrote: Here is a brief proposal for how we could simplify the current set of CORS headers. We can use this thread to evaluate whether it is worth breaking with what Firefox, Safari, Chrome, and IE are doing now. And whether all parties are willing to change their supported syntax in due course. Furthermore, I suggest that if we have nothing conclusive on this topic by June 15 we consider ISSUE-89[1] as resolved. We have to move on at some point. (Maybe the chairs should issue a CfC for this to make it official.) It seems we have actually something conclusive by today. Namely that we are not interested as a WG in renaming the headers of CORS. I will close the issue. [1]http://www.w3.org/2008/webapps/track/issues/89 -- Anne van Kesteren http://annevankesteren.nl/
Re: ISSUE-90: Exposing more (~infinite) response headers [CORS]
On Tue, 16 Jun 2009 16:18:25 +0200, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: In http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0967.html Mark Nottingham comments on the asymmetry of exposing the body of the response but only a tiny subset of the headers. He argues for * Expanding this whitelist and * Giving responses of resources a way to indicate which headers are ok to expose or * Turning it into a blacklist He indicated he was not satisfied deferring this issue to CORS2 and considers it a showstopper for CORS1. To resolve ISSUE-90 I added a new header Access-Control-Expose-Headers that controls which additional headers are exposed to the API. http://dev.w3.org/2006/waf/access-control/#http-access-control-expose-headers -- Anne van Kesteren http://annevankesteren.nl/
ACTION-438 Question about possibility of cross-site data sharing in Web Storage
At the TAG f2f meeting last week we discussed the Web Storage (http://dev.w3.org/html5/webstorage/) draft. As you know, Web Storage provides storage mechanisms (local storage and session storage) by origin. This led us to conclude that it supports the same-origin policy. But section 6.1 contains the sentence “User agents may allow sites to access session storage areas in an unrestricted manner, but require the user to authorize access to local storage areas.” This prompted some of us to speculate that a door is being left open for cross-site information sharing in the manner of CORS (http://www.w3.org/TR/access-control/)or UMP(http://www.w3.org/TR/UMP/). Would you agree that this reading between the lines is justified?
Re: [xhr] authorization
On Mon, 14 Jun 2010 20:58:07 +0200, Adam Barth w...@adambarth.com wrote: On Tue, Feb 16, 2010 at 6:28 AM, Anne van Kesteren ann...@opera.com wrote: On Sun, 06 Dec 2009 17:19:59 +0100, s...@rckc.at s...@rckc.at wrote: What about redirects that require different Authentication methods? How would that work? Testing shows that Firefox, Chrome, and Safari show an HTTP Auth dialog when making an XHR from a non-authenticated page to a URL that requires basic authentication. If an page with basic auth makes an XHR to a URL that requires digest auth, the user is prompted again for their user name and password: Username: ggg Password: ttt http://webblaze.org/abarth/tests/xhrauth/basic/todigest.html In the reverse situation, behavior differs by browser. http://webblaze.org/abarth/tests/xhrauth/digest/tobasic.html Here, Firefox allows the downgrade silently, but Safari and Chrome show the auth dialog again. I can test redirects too, if you like. If the user is now under (for example) a digest auth session, but the page/redirected page responds with Authentication: Basic, does the UA should prompt the user for user/password again? This is a dangerous downgrade attack (think active network attackers). Not sure. I would appreciate advice here. Also based on what we need with respect to legacy content. I'd recommend the Safari behavior, which is to re-prompt in these cases rather than the Firefox behavior, which is to silently allow the downgrade. If the session already has a username/password HTTP auth session and open() has user/pass? it should be replaced by the new one? Are you sure? Are you really sure? It would be good to get advice here too. This is slightly harder to test without a network sniffer, but here's a test case: http://webblaze.org/abarth/tests/xhrauth/basic/withotheruser.html When you visit that page, you need to type in your ggg/ttt username/password combination. In Firefox, Chrome, and Safari, the page prompts you again for a username/password because the page tries to make an XHR as hhh/qqq (this username doesn't exist on the server), which suggests that XHR should use the arguments to open instead of the ambient authentication. Notice that in Safari, the prompt is pre-filled with the username hhh, making it clear that the hhh/qqq authentication failed. Your text here makes is sound like you think there is some danger in this behavior. Would you care to elaborate? There are several attack scenarios there.. and unless I missed something in my opinion the specification is not specific enough =/ I can fix it if someone helps me out with the details. Let me know if there are other scenarios you'd like to test. The tests are pretty easy to run once you have a testbed working. I don't know too much about HTTP auth, so let me know if I've screwed up the test cases. Thanks a lot Adam! Thinking about it some more it seems that most of this is not really in scope of the XMLHttpRequest specification. XMLHttpRequest just indicates when the open() provided arguments are to be used. When authentication is considered to be a failure (e.g. downgrade) is not really up to XMLHttpRequest. I'd be open to making clarifications here but I cannot really think of anything that would help. -- Anne van Kesteren http://annevankesteren.nl/
Re: ISSUE-90: Exposing more (~infinite) response headers [CORS]
Anne van Kesteren wrote: On Tue, 16 Jun 2009 16:18:25 +0200, Web Applications Working Group Issue Tracker sysbot+trac...@w3.org wrote: In http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0967.html Mark Nottingham comments on the asymmetry of exposing the body of the response but only a tiny subset of the headers. He argues for * Expanding this whitelist and * Giving responses of resources a way to indicate which headers are ok to expose or * Turning it into a blacklist He indicated he was not satisfied deferring this issue to CORS2 and considers it a showstopper for CORS1. To resolve ISSUE-90 I added a new header Access-Control-Expose-Headers that controls which additional headers are exposed to the API. http://dev.w3.org/2006/waf/access-control/#http-access-control-expose-headers fantastic :)!
[WebIDL] NoInterfaceObject and access to constants
Hi all,
I am trying to provide access to constants defined in IndexedDB interfaces. For
example:
interface IDBRequest : EventTarget {
void abort ();
const unsigned short INITIAL = 0;
const unsigned short LOADING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
attribute Function onsuccess;
attribute Function onerror;
};
Given that this interface doesn't contain the modifier [NoInterfaceObject],
shouldn't it be possible to access the global object, e.g., window and from
that the interface and from that the constant? As an example:
window.IDBRequest.INITIAL or IDBRequest.INITIAL
For interfaces that should not be available as a property on the global object,
I need to apply the [NoInterfaceObject] modifier, but that doesn't apply here.
Can anyone confirm or refute this so that an open issue on the IndexedDB spec
can be closed without action?
Thanks,
Nikunj
Re: [IndexDB] Proposal for async API changes
(specifically answering out of context) On May 17, 2010, at 6:15 PM, Jonas Sicking wrote: 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest. We couldn't figure out how the old API allowed you to create a range object without first having a range object. Hey Jonas, What was the problem in simply creating it like it is shown in examples? The API is intentionally designed that way to be able to use constants such as LEFT_BOUND and operations like only directly from the interface. For example, IDBKeyRange.LEFT_BOUND; // this should evaluate to 4 IDBKeyRange.only(a).left; // this should evaluate to a Let me know if you need help with this IDL. Also, it might be a good idea to get the WebIDL experts involved in clarifying such questions rather than changing the API. Nikunj
CfC: Candidate Recommendation of XMLHttpRequest; deadline June 30
This is a Call for Consensus to publish a Candidate Recommendation of XMLHttpRequest: http://dev.w3.org/2006/webapi/XMLHttpRequest/ The comment period for the 19 November 2009 LCWD of XHR [LC] ended 16 December 2009 and the disposition of comments for this LCWD is: http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-3 During this CfC review period, Anne and Thomas agreed to work on the Security Considerations issue and others are welcome to contribute. A test suite has not been agreed by the Working Group, and will not be required for the CR to be published. However, agreeing on a test suite will be part of the work we will do before this spec can move further than CR. The Editor's Draft does not yet include CR exit criteria. I would expect the criteria to be similar to our previous CRs i.e. require a thorough test suite and at least two implementations that pass all tests. (We can discuss the criteria separately.) This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is June 30. -Art Barstow [LC] http://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro pablo.cas...@microsoft.com wrote: We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that. I'm also ok with keeping delete(), as well as continue(). This despite realizing that it might mean that different C++ implementations might map these names differently into C++. / Jonas
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro pablo.cas...@microsoft.com wrote: We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that. I'm also ok with keeping delete(), as well as continue(). This despite realizing that it might mean that different C++ implementations might map these names differently into C++. Isn't continue a _JS_ reserved word though?
Wanted: Editor for Web IDL spec
Hi All, A few of WebApps' specs, as well as specs from at least one other WG, have a normative dependency on the Web IDL spec [WebIDL]. Lack of progress on Web IDL (last published in Sept 2009 and only minor editing since then) will eventually block the dependent specs from advancing. Additionally, Cameron reported recently that October is the earliest he will be available to actively work on Web IDL. As such, we need at least one additional qualified person that can commit to helping to move the spec forward. Please let me know, as soon as you can, if you are interested in helping with this Editor role or you can recommend someone I should contact. -Thanks, Art Barstow [WebIDL] http://dev.w3.org/2006/webapi/WebIDL/
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/15/2010 12:40 PM, Jeremy Orlow wrote: On Tue, Jun 15, 2010 at 7:36 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 14, 2010 at 11:20 PM, Pablo Castro pablo.cas...@microsoft.com mailto:pablo.cas...@microsoft.com wrote: We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that. I'm also ok with keeping delete(), as well as continue(). This despite realizing that it might mean that different C++ implementations might map these names differently into C++. Isn't continue a _JS_ reserved word though? Not as a property on the primary expected target language, EcmaScript 5. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwXy9YACgkQ9VpNnHc4zAwlAwCguToFcLXY5FgGyL/7acDr4LKR LF0Anj96a/A6ChOeXCMHzlTv8A1xnhZy =TKKA -END PGP SIGNATURE-
Re: [IndexDB] Proposal for async API changes
On Tue, Jun 15, 2010 at 9:44 AM, Nikunj Mehta nik...@o-micron.com wrote: (specifically answering out of context) On May 17, 2010, at 6:15 PM, Jonas Sicking wrote: 9. IDBKeyRanges are created using functions on IndexedDatabaseRequest. We couldn't figure out how the old API allowed you to create a range object without first having a range object. Hey Jonas, What was the problem in simply creating it like it is shown in examples? The API is intentionally designed that way to be able to use constants such as LEFT_BOUND and operations like only directly from the interface. For example, IDBKeyRange.LEFT_BOUND; // this should evaluate to 4 IDBKeyRange.only(a).left; // this should evaluate to a Let me know if you need help with this IDL. Also, it might be a good idea to get the WebIDL experts involved in clarifying such questions rather than changing the API. If that is the intended syntax then that looks ok with me. What confused me was the IDL. We should definitely have keyrange stuff as a separate thread though, I'll start one today. / Jonas
[Bug 9903] Need to define specification and use of collations for string sorting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-15 20:00:55 --- The spec already does what the bug asks for. Check WebIDL for more help with access constants defined in interfaces. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9903] Need to define specification and use of collations for string sorting
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Comment #2 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-15 20:01:46 --- Wrong comment and closure -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 9888] Constants are not accessible when they're needed for most IndexedDB interfaces.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9888 Nikunj Mehta nikunj.me...@oracle.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME --- Comment #7 from Nikunj Mehta nikunj.me...@oracle.com 2010-06-15 20:02:27 --- The spec already does what the bug asks for. Check WebIDL for more help with access constants defined in interfaces. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Transferring File* to WebApps - redux
On 6/15/10 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: We would not be in favor of this transfer. We believe this API needs to be developed in the DAP group, as our vision for its functionality was driven by the input from BONDI and in general as a *device* API (as compared to an abstracted API for cloud-based file resources), and we do not believe that vision will be fulfilled if this work is transferred to Webapps. The BONDI API isn't a good starting place for an API that can be built into web browsers, since it doesn't gracefully layer into the existing HTML input element model for file selection. You are making a distinction I don't understand clearly, since we're not really considering cloud-based file resources with the FileReader API. Rather, we are considering file resources resident on the device. The API allows you to select them using an input element, and then access the file resource and programmatically manipulate it as a Blob. Similarly, the FileWriter API allows you to use the save as channel to write to the device in question. The FileSystem specification posits an abstraction that isn't necessarily cloud-based (although FWIW that is also possible). If you have a different vision, then that vision is incompatible with web browsers. In this case, I'd encourage the DAP WG, which *also* has a charter to work on file system deliverables, to construct an API which matches the use case you have in mind. You may then pursue the relevant BONDI API, which as a browser vendor I cannot consider. If the issue is the level of discussion in this group, that can be addressed. For one, I have seen quite a lot of traffic on the DAP email list about this, so I don't understand the question of activity. If you note the discussion on FileWriter, you'll see that the lion's share of feedback comes from cross-posts to public-weba...@w3.org. Feedback from others, including those that post to the DAP WG, is always welcome. But to start, I will address some of the open topics in the current draft on the DAP list, to help get the discussion moving faster. Again, I'd urge you to reconsider your position. The move of the specification in question -- FileWriter and FileSystem -- allows for greater collaboration on the same web stack, *and* allows parties that are NOT members of the DAP WG to comment on the technology. Perhaps you are misunderstanding the goals here? Or, perhaps you can provide a tighter definition of what you mean by cloud-based file resources *exactly*? DAP WG members are, by charter, free to consider technology that matches their particular use case. -- A*
RE: Transferring File* to WebApps - redux
Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via an input element?). Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. Thanks, Bryan Sullivan | ATT -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 1:48 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 1:15 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: We would not be in favor of this transfer. We believe this API needs to be developed in the DAP group, as our vision for its functionality was driven by the input from BONDI and in general as a *device* API (as compared to an abstracted API for cloud-based file resources), and we do not believe that vision will be fulfilled if this work is transferred to Webapps. The BONDI API isn't a good starting place for an API that can be built into web browsers, since it doesn't gracefully layer into the existing HTML input element model for file selection. You are making a distinction I don't understand clearly, since we're not really considering cloud-based file resources with the FileReader API. Rather, we are considering file resources resident on the device. The API allows you to select them using an input element, and then access the file resource and programmatically manipulate it as a Blob. Similarly, the FileWriter API allows you to use the save as channel to write to the device in question. The FileSystem specification posits an abstraction that isn't necessarily cloud-based (although FWIW that is also possible). If you have a different vision, then that vision is incompatible with web browsers. In this case, I'd encourage the DAP WG, which *also* has a charter to work on file system deliverables, to construct an API which matches the use case you have in mind. You may then pursue the relevant BONDI API, which as a browser vendor I cannot consider. If the issue is the level of discussion in this group, that can be addressed. For one, I have seen quite a lot of traffic on the DAP email list about this, so I don't understand the question of activity. If you note the discussion on FileWriter, you'll see that the lion's share of feedback comes from cross-posts to public-weba...@w3.org. Feedback from others, including those that post to the DAP WG, is always welcome. But to start, I will address some of the open topics in the current draft on the DAP list, to help get the discussion moving faster. Again, I'd urge you to reconsider your position. The move of the specification in question -- FileWriter and FileSystem -- allows for greater collaboration on the same web stack, *and* allows parties that are NOT members of the DAP WG to comment on the technology. Perhaps you are misunderstanding the goals here? Or, perhaps you can provide a tighter definition of what you mean by cloud-based file resources *exactly*? DAP WG members are, by charter, free to consider technology that matches their particular use case. -- A*
Re: Seeking pre-LCWD comments for Indexed Database API; deadline February 2
Hi, (brief background before jumping out of the blue: I'm working with Andrei and Jeremy with the IDB implementation..) I'd like to mention the IDBCursor::continue is also problematic, as afaict continue is a reserved keyword in JS? oh, delete seems to be reserved as well: https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Reserved_Words Not sure what to suggest though, perhaps move() ? We can't have next(), since the cursor is opened with a direction.. thoughts? Thanks, Marcus On Tue, Jun 15, 2010 at 7:20 AM, Pablo Castro pablo.cas...@microsoft.com wrote: From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Friday, June 11, 2010 3:20 PM So there is a real likelyhood of a browser implementation that will predate it's associated JS engine's upgrade to ES5? Feeling a concern isn't really much of technical argument on it's own, and designing for outdated technology is a poor approach. I don't think there is, just wanted to avoid imposing it. If you think it's really important then let's change it back to delete assuming other folks are good with it. I had the same concerns Pablo did, but I don't feel strongly either way. Besides the maneuvering we'll have to do on the C++ side of things to avoid clashes with language keywords, the question is whether we expect plugins and such to add support for IndexedDB in existing browsers that don't do ES5. For example: http://code.google.com/p/firebreath/wiki/FireBreathUsers Before we close on this, let me validate one more thing independently of the JS version. Are we going to have trouble when trying to expose these interfaces in C++? Not sure about other compilers and IDL processing tools, but I'm playing around with Visual Studio 2010 and while the COM IDL compiler will take delete as an interface member, my C++ compiler really doesn't like it. As far as I know there is no standard syntax to indicate that a symbol wasn't meant to be a keyword in C++, so having delete (or other C++ keywords for that matter) would be problematic. Am I missing something? Good point. Does anyone have a strong opinion on how much we should care about reserved word conflicts in language other than JavaScript? it seems like a slippery slope. As an example, IDBDatabase.description is actually used by the ObjectiveC base object class and so this caused some problems initially. We worked around it by having the ObjectiveC bindings generator add a suffix whenever an attribute named description is hit. (Something similar was done for hash and id in other APIs.) To be honest, I hadn't even considered bringing this up and asking for it to be changed, but if we're going to avoid delete because it's a reserved word in JavaScript (pre v5) and/or because it's a reserved word in C++, perhaps we should consider changing description as well? We've had to do this a few times in the past already. One example was Window.postMessage where we couldn't use the name PostMessage in C++ because it was a predefined macro on some platform (windows iirc, not to point fingers ;) ). :) We developed a similar trick where we can indicate in the IDL that different names are used for scripted languages and for compiled languages. So all in all I believe this problem can be overcome. I prefer to focus on making the JS API be the best it can be, and let other languages take a back seat. As long as it's solvable without too much of an issue (such as large performance penalties) in other languages. I agree we can sort this out and certainly limitations on the implementation language shouldn't surface here. The issue is more whether folks care about a C++ binding (or some other language with a similar issue) where we'll have to have a different name for this method. Even though I've been bringing this up I'm ok with keeping delete(), I just want to make sure we understand all the implications that come with that.. -pablo
Re: Transferring File* to WebApps - redux
On Tue, Jun 15, 2010 at 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via an input element?). The similarity between AJAX and the use-cases we're discussing is thin. XHR is the page communicating back with its origin server, and is security-wise in roughly the same category as a script adding an img to a page (the img sends a script-crafted request back to the server and receives data back). Interacting directly with the user's file system is a substantially more security-conscious action. Involving the user in the action, at least minimalloy, appears to be a common-sense good idea to mitigate the possibility of attacks. The decisions in this arena have been highly informed by security considerations specific to the particular cases being discussed. ~TJ
Re: ACTION-438 Question about possibility of cross-site data sharing in Web Storage
On Tue, 15 Jun 2010, Ashok Malhotra wrote: Would you agree that this reading between the lines is justified? Reading between the lines of a technical specification is never justified. The spec requires exactly what it says, no more, no less. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Transferring File* to WebApps - redux
On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via aninput element?). In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. But, by charter, the DAP WG allows you to address those very use cases! If the FileWriter, FileSystem, and FileReader specifications do NOT address the vision you articulate above, why not create a specification relevant to your use case? Naturally, browser vendors see value in technology that serves the cause of dynamic web pages. Why are you disallowing maximum browser vendor review by prohibiting a sensible move? Even within the DAP WG, feedback isn't as forthcoming on these specifications as it is in the WebApps WG. Please reconsider your stance here. You are not providing technical feedback on the specifications in question, nor illustrating why they don't address your use cases. But, you are blocking them from moving to a place where there *is* healthy technical feedback, worrying that those who *are* providing technical feedback will be poor custodians of a technology they are enthusiastic about building into their products. This is unfair. -- A*
Re: [WebIDL] NoInterfaceObject and access to constants
On Tue, 15 Jun 2010 16:56:31 +0200, Nikunj Mehta nik...@o-micron.com
wrote:
Hi all,
I am trying to provide access to constants defined in IndexedDB
interfaces. For example:
interface IDBRequest : EventTarget {
void abort ();
const unsigned short INITIAL = 0;
const unsigned short LOADING = 1;
const unsigned short DONE = 2;
readonly attribute unsigned short readyState;
attribute Function onsuccess;
attribute Function onerror;
};
Given that this interface doesn't contain the modifier
[NoInterfaceObject], shouldn't it be possible to access the global
object, e.g., window and from that the interface and from that the
constant? As an example:
window.IDBRequest.INITIAL or IDBRequest.INITIAL
Yes.
http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces
http://dev.w3.org/2006/webapi/WebIDL/#es-constants
For interfaces that should not be available as a property on the global
object, I need to apply the [NoInterfaceObject] modifier, but that
doesn't apply here.
Can anyone confirm or refute this so that an open issue on the IndexedDB
spec can be closed without action?
--
Simon Pieters
Opera Software
RE: Transferring File* to WebApps - redux
Jonas, I guess there might be a parting of the ways here, resulting from differing (I guess some would say, incompatible) use cases and the APIs that support them. If the current File APIs in DAP are expected to only serve the user-centric browser paradigm then I agree they will not meet the DAP requirements and could be finalized in Webapps. But in DAP we will still need to define an API that *does* meet the use cases and requirements as envisioned in BONDI (which are focused more on mobile use cases and security models, as compared to a desktop browser focus) and that are now being carried forward in the WAC. So to help move us forward with the use cases that matter most to us in DAP, ATT will draft a new API (filesystem) and provide that as input to the upcoming DAP F2F. Thanks, Bryan Sullivan | ATT -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, June 15, 2010 2:48 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On Tue, Jun 15, 2010 at 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via an input element?). Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. Hi Sullivan, I certainly agree that browsers aren't the only web context or use-case. However I strongly feel that we should design APIs for browsers separately from APIs where the security model is different from that of browsers. For example in a browser it is unacceptable for the web page to read the users file system without the user first granting access to this. And even then there are likely restrictions as to prevent users from getting hacked just because they clicked yes on a dialog they didn't understand and just wanted to go away (aka the whatever dialog problem). On the flip side, it might make a lot of sense for a widget running on a mobile phone, which some authority has authorized, to have read access to large parts of the phones file system. And possibly even write access to parts of it. However these differences in security model will likely lead to differences in API. This is ok. Lessons from the past, with for example the DOM-Core spec, show that if we try to create an API that fit too many different audiences (in that case it was both server-side environments, as well as web pages). I would really like to avoid repeating similar mistakes. So my suggestion is that we let the FileWriter and File System APIs be ones that are designed for the browser security model. And let them be designed in the webapps WG which is already working on several very similar features (for example I would argue that IndexedDB should supersede File system). If you or anyone else wants to design similar file related specifications, but that has different security model or otherwise different requirements than what exists in the web browser context, then this in no way should impact you. If this should happen in DAP, BONDI, or even in WebApps is a separate question which I basically don't have much of an opinion on at all. / Jonas
Re: Transferring File* to WebApps - redux
On Tue, Jun 15, 2010 at 3:11 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Jonas, I guess there might be a parting of the ways here, resulting from differing (I guess some would say, incompatible) use cases and the APIs that support them. If the current File APIs in DAP are expected to only serve the user-centric browser paradigm then I agree they will not meet the DAP requirements and could be finalized in Webapps. But in DAP we will still need to define an API that *does* meet the use cases and requirements as envisioned in BONDI (which are focused more on mobile use cases and security models, as compared to a desktop browser focus) and that are now being carried forward in the WAC. So to help move us forward with the use cases that matter most to us in DAP, ATT will draft a new API (filesystem) and provide that as input to the upcoming DAP F2F. That sounds great. Thank you! / Jonas
RE: Transferring File* to WebApps - redux
Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then ATT will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. Thanks, Bryan Sullivan | ATT -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 2:53 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via aninput element?). In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. But, by charter, the DAP WG allows you to address those very use cases! If the FileWriter, FileSystem, and FileReader specifications do NOT address the vision you articulate above, why not create a specification relevant to your use case? Naturally, browser vendors see value in technology that serves the cause of dynamic web pages. Why are you disallowing maximum browser vendor review by prohibiting a sensible move? Even within the DAP WG, feedback isn't as forthcoming on these specifications as it is in the WebApps WG. Please reconsider your stance here. You are not providing technical feedback on the specifications in question, nor illustrating why they don't address your use cases. But, you are blocking them from moving to a place where there *is* healthy technical feedback, worrying that those who *are* providing technical feedback will be poor custodians of a technology they are enthusiastic about building into their products. This is unfair. -- A*
Re: Transferring File* to WebApps - redux
Hi, Am I correct in thinking that what you find too restrictive is that the FileSystem API only allows programmatic access to a sandboxed portion of the device's filesystem instead of the entire filesystem? Otherwise, I believe that the File APIs as a whole will allow most of the other operations you mention. --mike On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then ATT will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. Thanks, Bryan Sullivan | ATT -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 2:53 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via aninput element?). In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. But, by charter, the DAP WG allows you to address those very use cases! If the FileWriter, FileSystem, and FileReader specifications do NOT address the vision you articulate above, why not create a specification relevant to your use case? Naturally, browser vendors see value in technology that serves the cause of dynamic web pages. Why are you disallowing maximum browser vendor review by prohibiting a sensible move? Even within the DAP WG, feedback isn't as forthcoming on these specifications as it is in the WebApps WG. Please reconsider your
RE: Transferring File* to WebApps - redux
Actually I think sandboxing an app into a certain area of the filesystem, especially for less-trusted apps, is a useful model. But I don't think the current File* APIs will support the items 5-6 that I mention below. 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs In BONDI, it's possible to define the sandbox as policy and avoid the user needing to select it. For example it's possible to restrict an application to: * a temp filesystem location (whatever that maps to on the current device) * other well-known filesystem locations * browser-internal storage (e.g. localstorage) Thanks, Bryan Sullivan | ATT From: Mike Clement [mailto:mi...@google.com] Sent: Tuesday, June 15, 2010 3:42 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux Hi, Am I correct in thinking that what you find too restrictive is that the FileSystem API only allows programmatic access to a sandboxed portion of the device's filesystem instead of the entire filesystem? Otherwise, I believe that the File APIs as a whole will allow most of the other operations you mention. --mike On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then ATT will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. Thanks, Bryan Sullivan | ATT -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 2:53 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via aninput element?). In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a
Re: Transferring File* to WebApps - redux
Bryan, On 6/15/10 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs I agree with you that those goals are incompatible with the File* APIs as they are currently evolving (although perhaps you can use these as the basis for interfaces and signatures, and swap out the invocation paradigm and the security paradigm separately within the W3C DAP WG). That being the case, let's agree to having separate DAP-oriented file APIs that address those particular use cases. I think that we agree that the FileWriter and FileSystem APIs as currently written (and with the current editor, Eric Uhrane) can move to WebApps, where they can evolve along with the existing File API specification. Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then ATT will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. At present time, I think that the paragraph above accurately summarizes a technical rift between certain members of both working groups (DAP and WebApps). It may not be worthwhile to resolve this rift, and we should allow disparate families of specifications to bloom, taking care not to cause developer confusion with naming (a hard problem). Where specifications worked on in the DAP WG lend themselves to implementation plans, I think Mozilla participants interested in these can comment on them (e.g. Contacts API, at least for now). -- A*
RE: Transferring File* to WebApps - redux
Mike, To be clear - I'm not saying that the current File* APIs are poorly designed or that they won't be useful. As I have read through them I agree there is a lot of the functionality that we are looking for in them and we appreciate the effort it took to create them, even though they are different from the BONDI API (there are many good ways to design such things). Extending them will be one option if we can't resolve the gaps in the APIs directly. But if we can count on a couple of key things then in the interest of having a single API for developers to use, I would agree we should focus on these APIs and see how far they can take us: 1) An app can use resolveLocalFilesystemURI directly to resolve a generic filesystem URI, e.g. documents, pictures, videos, music (we can create a normative set of these), or some other URI that is known to be supported by the device (which is itself known for example through the System Info API), e.g. file://home/user file:///\\home\user . Alternatively we can extend the LocalFilesystem interface with a getRootLocations method ala the BONDI filesystem API. 2) Access to resolveLocalFilesystemURI can be defined in policy (the resolve method can have an assigned feature URI used in widget config and policy documents), thus the user does not have to be prompted (if the app is trusted) or the input element used. Note that the alternatives requestPersistentFilesystem and requestTemporaryFilesystem are quite useful also, and may support the majority of use cases anyway. Thanks, Bryan Sullivan | ATT From: Mike Clement [mailto:mi...@google.com] Sent: Tuesday, June 15, 2010 4:40 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux As I understand it, #5 (programmatic access to files without user interaction) is indeed supported via the getFile method. But again, this is only within the sandboxed filesystem, not for an arbitrary file on the device. As for #6, I can't speak to the policy-framework approach, but I do know that the security provisions for manipulating files with regards to JavaScript will be the usual same-origin policy. --mike On Tue, Jun 15, 2010 at 3:55 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Actually I think sandboxing an app into a certain area of the filesystem, especially for less-trusted apps, is a useful model. But I don't think the current File* APIs will support the items 5-6 that I mention below. 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs In BONDI, it's possible to define the sandbox as policy and avoid the user needing to select it. For example it's possible to restrict an application to: * a temp filesystem location (whatever that maps to on the current device) * other well-known filesystem locations * browser-internal storage (e.g. localstorage) Thanks, Bryan Sullivan | ATT From: Mike Clement [mailto:mi...@google.com] Sent: Tuesday, June 15, 2010 3:42 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: a...@mozilla.com; Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux Hi, Am I correct in thinking that what you find too restrictive is that the FileSystem API only allows programmatic access to a sandboxed portion of the device's filesystem instead of the entire filesystem? Otherwise, I believe that the File APIs as a whole will allow most of the other operations you mention. --mike On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then ATT will
