SULLIVAN, BRYAN L (ATTCINW) wrote:
Marcos,
Re I'm personally not in favor of trying to deviate too much from the Web security model.: I agree with you,
and that is the point of the comments. The web security model (I think you mean the same-origin restriction)
does not restrict access to
Hi,
I understand it might be too late to modify the spec now but I still think the
spec isn't clear with regards to icon size and should be clarified, maybe in
some future version at least. I'm also not fully convinced your description
(bottom of this mail) about clipping an SVG icon is
Hi,
I alluded to this during the joint F2F meeting between WebApps and DAP
last week, but thought I would make the proposal more formally: given
that the current “File API” [1] really defines a FileReader interface,
and given that DAP is supposed to come up with a more generic
filesystems API
Which is the proper mailing list to follow development of the file
writing API? I'd like to follow it's security considerations.
Thanks,
Adam
On Tue, Nov 10, 2009 at 1:56 AM, Dominique Hazael-Massieux d...@w3.org wrote:
Hi,
I alluded to this during the joint F2F meeting between WebApps and
On Wed, 04 Nov 2009 06:27:53 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
This is a Call for Consensus (CfC) to publish the First Public Working
Draft (FPWD) of the File API spec, latest Editor's Draft at:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
I support
On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote:
On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth w...@adambarth.com
wrote:
Which is the proper mailing list to follow development of the file
writing API? I'd like to follow it's security considerations.
public-device-a...@w3.org
At
Le mardi 10 novembre 2009 à 02:27 -0800, Maciej Stachowiak a écrit :
At TPAC, I recall that we proposed drawing the line between file
reading/writing on the one hand (presumably to go in the current File
API spec) and filesystem access (including messing with directories,
mountpoints,
On Nov 10, 2009, at 11:27 , Charles McCathieNevile wrote:
I support publication of the document, but suggest that it be named
File Reader API or something to reduce the confusion with the more
complete File API being edited in DAP.
+1 to File Reader API. I think we can keep all of this
On Nov 10, 2009, at 11:27 , Maciej Stachowiak wrote:
On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote:
On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth w...@adambarth.com
wrote:
Which is the proper mailing list to follow development of the file
writing API? I'd like to follow it's
I added support for Blob and FormData to XMLHttpRequest Level 2 also based
on the discussion at the F2F:
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/
More comments below.
On Tue, 20 Oct 2009 10:28:57 -0700, Darin Fisher da...@chromium.org
wrote:
Sorry... I just meant that I need to
Marcos,
I agree there is an assumption behind the approach I proposed, which I also
believe will be valid for the vast majority of widgets which will actually have
index.html or something like that as the start page. Further, the statements
in the config.xml apply to all resources in the
I resolved ISSUE-103 by removing exceptions for the getters as discussed
during the F2F meeting. I don't believe there is anything else outstanding
so we can try another Last Call I think. Do we need a CfC through email as
well maybe before I request to publish that?
--
Anne van Kesteren
On Wed, 11 Nov 2009 01:13:56 +0100, Anne van Kesteren ann...@opera.com
wrote:
I resolved ISSUE-103 by removing exceptions for the getters as discussed
during the F2F meeting. I don't believe there is anything else
outstanding so we can try another Last Call I think.
Do we need a CfC
SULLIVAN, BRYAN L (ATTCINW) wrote:
Marcos,
I agree there is an assumption behind the approach I proposed, which I also believe will be valid
for the vast majority of widgets which will actually have index.html or something like
that as the start page. Further, the statements in the
Yay!
On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote:
WebKit presently supports sending File. It does not support FileData
yet.
Is Content-Type set to anything specific if the author has not set it?
// FIXME: Should we set a Content-Type if one is not set.
^^^
Marcos,
Re the whole point of WARP is to put these boundaries around the behavior of
widgets because they run locally., there is really no difference between
browser-context and widget-context webapps in that sense. Both run on the
device, and both can access device resources and network
Le mardi 03 novembre 2009 à 21:27 -0800, Arthur Barstow a écrit :
This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the File API spec, latest Editor's Draft at:
http://dev.w3.org/2006/webapi/FileAPI/
My understanding is that the FPWD would have a
The name of the file as a UTF8-encoded string. A DOMString is not
UTF-8-encoded. I think this should just say Returns the filename. It is
not more complicated than that as far as I can tell.
--
Anne van Kesteren
http://annevankesteren.nl/
It might make sense to rename INITIAL to EMPTY for consistency with
HTMLMediaElement. Instead of LOADING READING might be better though I care
less about that one.
--
Anne van Kesteren
http://annevankesteren.nl/
Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :
Some use cases:
[…]
* Ability to write a Web-based photo management application that handles
the user's photos on the user's computer
* Ability to expose audio files to native media players
* Ability to write a Web-based media
On 11/10/09 8:33 PM, Anne van Kesteren wrote:
This should be a bit more exact as to how the mediaType is returned. I
would prefer ASCII-lowercase. Returning application/octet-stream
rather than null also seems better if the type is not known. That way
you do not have to type check. Other parts
The design of the FileReader API is a bit awkward. It's sort of the
inverse of the XMLHttpRequest API (by having separate read methods rather
than separate response getters) though the moment we add support for octet
streams we get both? Or will the result attribute start to return
On Tue, 10 Nov 2009 17:53:14 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/10/09 8:33 PM, Anne van Kesteren wrote:
This should be a bit more exact as to how the mediaType is returned. I
would prefer ASCII-lowercase. Returning application/octet-stream
rather than null also seems better if
On Tue, Nov 10, 2009 at 5:22 PM, Anne van Kesteren ann...@opera.com wrote:
I was looking at defining the timeout feature. For consistency with abort
error and network error it would make sense to introduce a TIMEOUT_ERR
for synchronous requests, but Internet Explorer is probably not doing this
On Tue, 10 Nov 2009 18:23:04 +0100, Jonas Sicking jo...@sicking.cc wrote:
Are all of these comments for synchronous XHR only?
Only the TIMEOUT_ERR exception was for the synchronous case. I think the
synchronous case it would be most consistent to not dispatch any events.
This is however
On 11/10/09 11:58 AM, Anne van Kesteren wrote:
True, can you ever get this situation when reading a file from disk?
I'm not sure what you're asking... When loading a file from disk, the
type is always unknown and has to be determined by the UA somehow, no?
Sure, but there's also
On Tue, Nov 10, 2009 at 8:56 AM, Anne van Kesteren ann...@opera.com wrote:
The design of the FileReader API is a bit awkward. It's sort of the inverse
of the XMLHttpRequest API (by having separate read methods rather than
separate response getters) though the moment we add support for octet
On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren ann...@opera.com wrote:
I agree that firing readystatechange seems like the most consistent thing
to do.
I agree that firing timeout (and IMHO abort) on the XHRUpload object
unless upload has already finished.
In general, I think
On Tue, 10 Nov 2009 18:41:32 +0100, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren ann...@opera.com
wrote:
abort() has some legacy attached to it that I rather not copy.
Such as?
Actually, apart from switching the state to 0 in the end there is
I've updated the web page that describes the calendar access grant. See:
http://sites.google.com/site/guestxhr/maciej-challenge
More comments inline below...
On Wed, Nov 4, 2009 at 6:14 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 4, 2009, at 6:04 PM, Maciej Stachowiak wrote:
I
I've elaborated on the example at:
http://sites.google.com/site/guestxhr/maciej-challenge
I've tried to include all the information from our email exchange.
Please let me know what parts of the description remain ambiguous.
Just so that we're on the same page, the prior description was only
Thanks for clarifying your protocol. How does this protocol compare
to OAuth? The two appear to be solving the same problem with the same
set of constraints. I ask because OAuth has had a series of subtle
security vulnerabilities that eluded early security folks who analyzed
the protocol.
I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nikunj R. Mehta wrote:
Hi Kris,
Thanks for the insightful feedback.
On Nov 7, 2009, at 8:12 PM, Kris Zyp wrote:
Is there any intended restrictions on caching of objects returned by
queries and gets with WebSimpleDB?
Currently, the spec
On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:
I alluded to this during the joint F2F meeting between WebApps and DAP
last week, but thought I would make the proposal more formally: given
that the current “File API” [1] really defines a FileReader
interface, and given that DAP is
On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:
Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :
Some use cases:
[…]
* Ability to write a Web-based photo management application that handles
the user's photos on the user's computer
* Ability to expose audio files
Anne has now resolved the last issue for XHR (1) and as discussed
during last week's f2f meeting [1], the spec is ready for a Last Call
Working Draft publication:
http://dev.w3.org/2006/webapi/XMLHttpRequest/
This CfC satisfies the group's requirement to record the group's
decision to
On Tue, Nov 10, 2009 at 10:17 AM, Anne van Kesteren ann...@opera.com wrote:
On Tue, 10 Nov 2009 18:41:32 +0100, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 10, 2009 at 9:29 AM, Anne van Kesteren ann...@opera.com
wrote:
abort() has some legacy attached to it that I rather not copy.
On Tue, Nov 10, 2009 at 2:01 PM, Arthur Barstow art.bars...@nokia.com wrote:
Anne has now resolved the last issue for XHR (1) and as discussed during
last week's f2f meeting [1], the spec is ready for a Last Call Working Draft
publication:
http://dev.w3.org/2006/webapi/XMLHttpRequest/
This
Dominique Hazael-Massieux wrote:
Le mardi 03 novembre 2009 à 21:27 -0800, Arthur Barstow a écrit :
This is a Call for Consensus (CfC) to publish the First Public
Working Draft (FPWD) of the File API spec, latest Editor's Draft at:
http://dev.w3.org/2006/webapi/FileAPI/
My
On Nov 10, 2009, at 5:29 PM, Anne van Kesteren wrote:
The name of the file as a UTF8-encoded string. A DOMString is not
UTF-8-encoded. I think this should just say Returns the filename.
It is not more complicated than that as far as I can tell.
There are some filesystems on (mostly
I support this publication.
- Maciej
On Nov 10, 2009, at 2:01 PM, Arthur Barstow wrote:
Anne has now resolved the last issue for XHR (1) and as discussed
during last week's f2f meeting [1], the spec is ready for a Last
Call Working Draft publication:
On Nov 10, 2009, at 3:09 AM, Robin Berjon wrote:
On Nov 10, 2009, at 11:27 , Maciej Stachowiak wrote:
On Nov 10, 2009, at 2:01 AM, Arve Bersvendsen wrote:
On Tue, 10 Nov 2009 10:59:23 +0100, Adam Barth w...@adambarth.com
wrote:
Which is the proper mailing list to follow development of
Gervase Markham wrote on 10/01/2009 5:51 PM:
I therefore propose a simple extension to the STS standard; a single
token to be appended to the end of the header:
lockCA
One idea to consider, especially for lockCA, is to somehow denote that STS
should expire at the same time as the cert,
On Tue, Nov 10, 2009 at 5:53 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 10, 2009, at 12:36 PM, Ian Hickson wrote:
On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:
Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :
Some use cases:
[…]
* Ability to write a
On Tue, 10 Nov 2009 21:36:36 +0100, Ian Hickson i...@hixie.ch wrote:
On Tue, 10 Nov 2009, Dominique Hazael-Massieux wrote:
Le lundi 09 novembre 2009 à 20:08 +, Ian Hickson a écrit :
Some use cases:
[…]
* Ability to write a Web-based photo management application that
handles
the
45 matches
Mail list logo
