Hi,
the spec lists a use case about a web app that needs to send file(s) to the
server programmatically. I happen to think lately about an E-mail app that
can send attachments. FileData and its splice() method are useful here. I
assume the XHR2 spec would get XHR.send(FileData) method. XHR2
Hi,
Does the Blob, which is obtained as File (so it refers to an actual file on
disk) track the changes in the underlying file and 'mutates', or does it
represent the 'snapshot' of the file, or does it become 'invalid'?
Today, if a user selects a file using input type=file, and then the file
on
decided when we did security review on this
stuff at mozilla is that if a File object is ever passed cross origin
using postMessage, then the File object that the other origin has
should not work if the file is changed on disc. For some definition of
not work.
On Fri, Jan 8, 2010 at 2:21 PM, Dmitry
Atomic read is obviously a nice thing - it would be hard to program against
API that behaves as unpredictably as a single read operation that reads half
of old content and half of new content.
At the same note, it would be likely very hard to program against Blob
objects if they could change
, 2010 at 12:10 PM, Dmitry Titov dim...@chromium.org wrote:
On Fri, Jan 15, 2010 at 11:50 AM, Jonas Sicking jo...@sicking.cc wrote:
This doesn't address the problem that authors are unlikely to even
attempt to deal with this situation, given how rare it is. And even
less likely to deal
On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote:
I think it could. Here's a third option:
Make all blobs, file-based or not, just as async as the blobs in
option 2. They never do sync IO, but could potentially fail future
read operations if their metadata is out of
and introduce
File.getAsBlob() as dimich suggested. This seems to be more elegant.
However, it requires changing the File API spec a lot.
On Wed, Jan 20, 2010 at 3:44 PM, Eric Uhrhane er...@google.com wrote:
On Wed, Jan 20, 2010 at 3:23 PM, Dmitry Titov dim...@chromium.org
wrote
Going a bit back to current spec and changing underlying files - here is an
update on our thinking (and current implementation plan). We played with
File/Blob ideas a little more and talked with some of our app developers. In
regard to a problem of changing file, most folks feel the Blob is best
I can't help but think the Growl issue is way overblown. I am the user who
uses Growl and also a GoogleTalkLabsEdition for Mac that pop ups nice
notifications about upcoming meetings, email and chat. Growl is connected to
IRC and something else (don't even remember). They both use top-right corner
On Fri, Feb 12, 2010 at 5:32 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi WebApps fans!
Working on implementing FormData and ran into a couple of questions.
First of all, I assume that it is intended that a FromData object can
be submitted several times. I.e. that the following code is ok:
On Sat, Feb 13, 2010 at 6:44 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sat, Feb 13, 2010 at 6:02 PM, Dmitry Titov dim...@chromium.org wrote:
On Fri, Feb 12, 2010 at 5:32 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi WebApps fans!
Working on implementing FormData and ran into a couple
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 10, 2010, at 20:35, John Gregg wrote:
I agree that this is a good distinction, but I think even considering
ambient notifications there is a question of how much interaction should be
supported. NotifyOSD, for
To be even safer, I'd remove dashes from it... I never knew why GUIDs have
those dashes - to make them easier to memorize? :-)
Seriously though, it would be nice to have XHR2 spec to have these details
spelled out, especially mime type (I think David meant
application/octet-stream)
Dmitry
On
Blob would need a content-type for that, but it could probably easy be added
as a property that is assignable.
BTW if the Blob could have a urn and mime type, this info could be directly
used to form the headers for the Blob when sending it in multipart form
using FormData.
Dmitry
On Tue, Mar
Those seem to open up so many edge cases...
If we have a File constructor like this, now we have a new category of File
objects that do have names but are not related to actual files on a local
file system, and perhaps have different lifetime expectations.
Ability to specify a name and content
On Fri, Apr 2, 2010 at 5:34 PM, Eric Uhrhane er...@google.com wrote:
On Tue, Mar 30, 2010 at 2:57 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Mar 30, 2010 at 12:22 AM, Jonas Sicking jo...@sicking.cc
wrote:
On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org
wrote:
On Tue, May 18, 2010 at 2:56 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/18/10 2:35 PM, Eric Uhrhane wrote:
On Mon, May 17, 2010 at 3:37 PM, Dmitry Titovdim...@chromium.org
wrote:
I have couple of questions, mostly clarifications I think:
1. FileReader takes Blob but there are
+1 to
window.createBlobUrl(blob) and
window.revokeBlobUrl(url)
, they make lifetime of a blob url (which is different from lifetime of the
Blob JS object) way more clear to me, since it attaches it explicitly to a
window, and to a specific window in that. Multi-window web apps (like GMail
or IM)
Tying a 'lifetime' of a string url to a blob which is not even needed at the
point of use seems to be creating a mechanism that doesn't generally work:
function getImageUrl() {
var a_blob = ... load a blob in some way, perhaps via XHR
return a_blob.url;
}
... // sometime during
On Fri, Jul 23, 2010 at 12:15 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 23 Feb 2010, Drew Wilson wrote:
This was recently brought to my attention by one of the web app
developers
in my office:
http://dev.w3.org/2006/webapi/FileAPI/#lifeTime
User agents MUST ensure that the
Thanks Jonas,
Just to clarify some details we had while discussing this, could you confirm
if this matches with your thinking (or not):
1. If blob was created in window1, blob.url was queried, then passed (as JS
object) to window2, and window1 was closed - then the url gets invalidated
when
As for wild ideas, it also could be something more generic, lets say
DataReader which can take Blobs and Files (and perhaps something else in the
future). Like XHR that has overloaded methods for xhr.open(..).
It seems possible that web developers may not realize that File is actually
a Blob and
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in case
of having those functions on URL interface object?
If those methods are on a global object, the lifetime of the urls created
would be gated by the lifetime of that
at 11:57 AM, Michael Nordman micha...@google.comwrote:
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov dim...@chromium.org
wrote:
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in
case
of having those functions on URL
On Tue, Nov 16, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 16, 2010 at 12:07 PM, Dmitry Titov dim...@chromium.org
wrote:
Thanks Michael,
so the proposed change is this: window.createObjectURL -
window.URL.createObjectURL
and it means it's also possible to do
Sounds reasonable, and close to what IE and WebKit implement...
Seems the clipboardData object may simply implement
dataTransferhttp://dev.w3.org/html5/spec/dnd.html#the-datatransfer-interfaceinterface.
This would give it legacy setData/getData as well as
items
Taking back the claim about Safari :-) It doesn't have File.slice indeed.
Sorry about that.
On Tue, Apr 12, 2011 at 1:36 PM, Dmitry Titov dim...@chromium.org wrote:
Indeed, it appeared in FF 4 which was shipped end of March, so if it was
only FF API, it would be fine to change it since it's
It can be more then it looks though - if site detects File.slice and then
uses it, it will automatically pick up FF and Opera now because the method
now is defined. But the code is assuming the 'length' semantics of the
second parameter. So if the site is using recommended method of detection,
the
28 matches
Mail list logo
