Fwiw, to the extent it may be helpful when it comes to spec writing, here
are some quick-n-dirty thoughts about how some approximation of the
'autorevoke' behavior could be implemented in chromium.
1) Extend the lifetime of the PublicBlobURL registration until *after* the
last latchee has
This could be accomplished with a separate pub/sub capability, instead of
complicating the IDB interfaces and allocating new functions to that
component.
We (chromium project) have open bug about a broadcastMessage function.
https://code.google.com/p/chromium/issues/detail?id=161070
On Tue, Feb
Making offline apps easier?
Feels like we're still at the 'make it possible' phase more so than the
'make it easier' phase.
I think it's fitting that appcache and widgets were listed at opposite ends
in your list because the intent of the former is to make it possible for
drive-by-web sites to
The appcache is encumbered with guarantees about atomically updating a set
of resources and then explicitly not hitting the network for them once up
to date to ensure the site/app will function if the network really is
complete gone.
This gist of this prefetch list seems different. More of a hint
The URLObject proposal is a pretty slick way of cooking up a request in
contextA for later (and all manner of) retrieval in contextB.
On Thu, Aug 2, 2012 at 4:23 PM, Glenn Maynard gl...@zewt.org wrote:
I'd suggest the following.
- Introduce an interface URLObject (bikeshedding can come
Maybe another XHR based way to phrase this: define a new response type for
XHR that results in the construction of a lazyBlob. I guess that's similar
to the more explicit xhr.makeLazyBlob() method, but allows its construction
to be async, and for greater reuse of the same signaling for progress
Sounds like there's a good case for an explicit blob.close() method
independent of 'transferable'. Separately defining blobs to be
transferrable feels like an unneeded complexity. A caller wishing to
neuter after sending can explicit call .close() rather than relying on
more obscure artifacts of
Separately defining blobs to be transferrable feels like an unneeded
complexity. A caller wishing to
neuter after sending can explicit call .close() rather than relying on
more obscure artifacts of having also put the 'blob' in a
'transferrable' array.
You can always call close() yourself,
and MUST be at least 36 characters long
I can't think of any reason for that requirement, seems fine to delete it.
Webkit and Chrome do use guids but also embed the origin in these url.
On Fri, Dec 16, 2011 at 5:58 AM, Jarred Nicholls jar...@webkit.org wrote:
On Fri, Dec 16, 2011 at 6:27
There is no requirement for that in the spec/draft, it's useful for our
implementation.
On Fri, Dec 16, 2011 at 3:06 PM, Charles Pritchard ch...@jumis.com wrote:
Is there something requiring that the origin be part of the URL?
On Dec 16, 2011, at 2:29 PM, Michael Nordman micha...@google.com
This ultimately amounts to syntactic sugar compared to the existing api.
It's tasty, but adds no new functionality. Also there's still the issue of
how this new api would provide the existing functionality around line
endings, so less functionality at the moment. I'm not opposed to
It's nice. Like Ojan said, I don't see this as mutually exlusive with
BlobBuilder either. There's nother peice of data to associate with a
blob... the content-type... that would need to be provided in the ctor.
On Mon, Oct 24, 2011 at 4:01 PM, Ojan Vafai o...@chromium.org wrote:
On Mon, Oct 24,
The behavior Israel describes is the behavior that I would expect as a
developer.
On Fri, Oct 14, 2011 at 1:51 PM, Israel Hilerio isra...@microsoft.comwrote:
On Friday, October 07, 2011 4:35 PM, Israel Hilerio wrote:
On Friday, October 07, 2011 2:52 PM, Jonas Sicking wrote:
Hi All,
On Tue, Sep 27, 2011 at 1:26 PM, Charles Pritchard ch...@jumis.com wrote:
On 9/27/2011 9:43 AM, Jonas Sicking wrote:
On Tue, Sep 27, 2011 at 6:12 AM, Kinuko Yasudakin...@chromium.org
wrote:
Just to confirm: Yes the interfaces are vendor prefixed (WebKit), and
WebSQL, AppCache, IDB are
On Mon, Sep 26, 2011 at 4:53 PM, Charles Pritchard ch...@jumis.com wrote:
The callback style is prevalent in the File API, as well as IndexedDB. It
seems quite fitting to me. Am I missing something?
They are using vendor prefixing (WebKit).
From what I read, WebSQL is temporary: I've not
2011/8/23 Jonas Sicking jo...@sicking.cc
On Tue, Aug 23, 2011 at 12:53 AM, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 23 Aug 2011 02:25:38 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Given that this seems to be the way people prefer to do it, I'm fine
with doing that for Gecko
A few of us on the chrome team just discussed this. We see this as a
deficiency in the FormData interface and intend to address it by providing a
variant of FormData.append(...) that allows the caller to provide a
'filename' when appending a blob. We don't intend to implement
The problem is around naming the binary parts attached to
multi-part-form-encoded FormData. I think I'm in favor of the more direct
solution to this problem, providing a FormData.append() variant that
optionally allows the caller to specify a name. If no name is provided and
the blob is a File,
2011/4/7 Michael Nordman micha...@google.com
2011/4/7 louis-rémi BABE lrb...@gmail.com
Thank you all for your valuable answers.
There seems to be a pretty solid agreement on ability to exclude the
master page form the cache.
Michael, you are suggesting using a different way of referring
2011/4/7 louis-rémi BABE lrb...@gmail.com
Thank you all for your valuable answers.
There seems to be a pretty solid agreement on ability to exclude the
master page form the cache.
Michael, you are suggesting using a different way of referring to the
manifest: http useManifest='x'
Why not
AM, Arthur Barstow art.bars...@nokia.comwrote:
Michael, All,
On Mar/31/2011 6:18 PM, ext Michael Nordman wrote:
I have in mind several extensions to the ApplicationCache that I think
could address some of the additional desirements from the web developement
community. I'll post them here
Hi again,
I have in mind several extensions to the ApplicationCache that I think could
address some of the additional desirements from the web developement
community. I'll post them here because people seem to be more willing to
have a discussion on the topic here than over in whatwg.
1. Allow
Not sure if this is what you're looking for, but the
http://www.html5rocks.com/ site provides a developer facing view of these
things.
On Mon, Mar 28, 2011 at 6:21 AM, Arthur Barstow art.bars...@nokia.comwrote:
Hi All,
Louis-rémi's thread [1] on AppCache led to discussions about other storage
Hi Louis,
It's good to see some interest in the AppCache from the mozilla camp. My
take on one thing that what went wrong is that the community of browser
vendors stopped engaging on the topic, so I'm happy to see you posting here.
You pointed out two features that have been often requested.
-
On Tue, Dec 21, 2010 at 11:31 AM, Arun Ranganathan a...@mozilla.com wrote:
I have updated the editor's draft of the File API (special winter solstice
edition).
In particular:
On 12/20/10 8:32 PM, Michael Nordman wrote:
On Mon, Dec 20, 2010 at 4:08 PM, Arun Ranganathana...@mozilla.com
On Mon, Dec 20, 2010 at 4:08 PM, Arun Ranganathan a...@mozilla.com wrote:
On 12/20/10 5:38 PM, Jian Li wrote:
On Mon, Dec 20, 2010 at 2:10 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 20 Dec 2010, Arun Ranganathan wrote:
http://dev.w3.org/2006/webapi/FileAPI/
Notably:
1.
On Tue, Nov 16, 2010 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
We have at length discussed what revokeObjectURL should be called, and
where it should live. However we haven't yet discussed how it should
behave.
In particular, there is one edge case that I'm concerned about.
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 interface object?
If those methods are on a global
Personally, I don't think new response modes is the proverbial straw
that breaks the camel's back.
I don't see the problem with selecting the responseType up front
either. It doesn't feel like a new class of object is warranted just
to provide the response body different forms. As Jonas pointed
There are two distinct parts to the DataCache draft.
http://www.w3.org/TR/2009/WD-DataCache-20091029/
1. The DataCache part, programmatically adding resources to the cache, the
DataCache part.
2. The LocalServer part, having application script determine/produce the
response to a request, handling
Darin mentioned it earlier in this thread, having XHR return the raw data
and providing other interfaces to interpret/decode the raw data into
strings/xmlDocs. I like that decomposition.
Because I'm skeptical that nested libraries trying to access the data both
ways will be an issue.
I'm not
On Wed, Oct 27, 2010 at 12:34 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/27/10 3:23 PM, Michael Nordman wrote:
Darin mentioned it earlier in this thread, having XHR return the raw
data and providing other interfaces to interpret/decode the raw data
into strings/xmlDocs. I like
I'm in favor of adding the explicit asArrayBuffer attribute. Simple and
straight forward for both web developers and browser developers.
On Tue, Oct 26, 2010 at 3:39 PM, Chris Rogers crog...@google.com wrote:
On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On
Chrome currently has this as...
DOMString createBlobURL(in Blob blob);
void revokeBlobURL(in DOMString blobURL);
... no prefix... on both Window and WorkerContext.
An important aspect of placing these interfaces on the Window and
WorkerContext was to scope the lifetime of the
A couple of us have been looking at webkit's XHR impl and realized that to
support performant access to the response via responseArrayBuffer and
responseText would cause us to keep two copies of the data around, a raw
data buffer and the second decoded text buffer. Considering the overwhelming
On Tue, Sep 7, 2010 at 12:12 PM, Adrian Bateman adria...@microsoft.comwrote:
On Tuesday, September 07, 2010 11:46 AM, Chris Prince wrote:
1. Most people that I talk to dislike the name Blob, much less having
it spread to things like BlobReader.
I could maybe understand this if blob
, Anne van Kesteren ann...@opera.com wrote:
On Tue, 17 Aug 2010 21:14:03 +0200, Michael Nordman micha...@google.com
wrote:
On Mon, Aug 16, 2010 at 11:34 PM, Anne van Kesteren ann...@opera.com
wrote:
Yeah I have. This design looks rather good. We should also define what
happens
On Tue, Aug 17, 2010 at 3:37 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 18 Aug 2010 00:24:56 +0200, Michael Nordman micha...@google.com
wrote:
Blob attribute responseBlob;
// Returns a blob the contains the response body.
// Only valid to access when asBlob is true and when
On Thu, Jul 29, 2010 at 4:33 PM, Jonas Sicking jo...@sicking.cc wrote:
Sorry about the slow response. I'm currently at blackhat, so my
internet connectivity is somewhat... unreliable, so generally having
to try to stay off the webs :)
On Tue, Jul 27, 2010 at 1:16 PM, Dmitry Titov
On Thu, Jul 1, 2010 at 11:47 AM, Dmitry Titov dim...@chromium.org wrote:
+1 to
window.createBlobUrl(blob) and
window.revokeBlobUrl(url)
+1 too, presumably these would also be available workers, particularly
shared workers.
, they make lifetime of a blob url (which is different from
On Wed, Jun 30, 2010 at 10:29 AM, Eric Uhrhane er...@google.com wrote:
On Wed, Jun 30, 2010 at 10:18 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jun 29, 2010 at 5:17 PM, Eric Uhrhane er...@google.com wrote:
Following up on discussions mainly at [1] and use cases at [2], I'd
like to
On Mon, Jun 28, 2010 at 6:58 PM, Eric Uhrhane er...@google.com wrote:
The discussion at [1] got tangled up with the debate of .URL vs. .url,
so I'm starting a new thread to pick back up the original topic: how
do we save binary data from XMLHttpRequest? Here's my proposal [built
mainly from
Another advantage is that...
blobdata://
http_responsible_party.org:80/3699b4a0-e43e-4cec-b87b-82b6f83dd752
... makes it clear to the end user who the responsible party is when these
urls are visible in the user interface. (location bar, tooltips, etc).
On Fri, Jun 11, 2010 at 11:11 AM, Jonas
This sounds very similar to the strategy used for WebSQLDatabase.
On Tue, May 18, 2010 at 1:54 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, May 13, 2010 at 10:25 AM, Shawn Wilsher sdwi...@mozilla.com
wrote:
On 5/13/2010 7:51 AM, Nikunj Mehta wrote:
If you search archives you will
On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking jo...@sicking.cc wrote:
Ugh, sent this originally to just Darin. Resending to the list.
On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue,
This thinking resonates with what we've been thinking too (I think).
On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote:
We had some discussions about this at mozilla yesterday. I think the
summary is something like this:
* We'd like to expire data in IndexDB after some
On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher da...@chromium.org
wrote:
,
kept only in memory. Such databases are required to be empty upon creation.
They may be spilled over to disk, if implementations like to, but they will
not be retained from session to session.
Nikunj
On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote:
I'd like to back up and challenge
are required to be empty upon creation.
They may be spilled over to disk, if implementations like to, but they will
not be retained from session to session.
Nikunj
On Apr 20, 2010, at 2:37 PM, Michael Nordman wrote:
I'd like to back up and challenge the notion of a per-site quota
On Tue, Apr 13, 2010 at 9:01 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 13, 2010 at 7:35 PM, Michael Nordman micha...@google.com
wrote:
Good question. Let me ask you one. What value should you use for the
content-type header? That value needs to contain the boundary string. You
much a need... but to make the programming
interface symmetrical and hopefully easier to understand and use.
On Tue, Apr 13, 2010 at 6:03 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 13, 2010 at 5:53 PM, Michael Nordman micha...@google.com
wrote:
On Tue, Apr 13, 2010 at 5:39 PM
There is more than just the mime type when dealing with the URLs.
There at least two content headers of interest, Content-Type
and Content-Disposition.
Whatever mechanism involved should allow for both of these content headers
to be set
by the web application.
On Tue, Mar 30, 2010 at 3:07 PM,
Kesteren ann...@opera.com wrote:
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@google.com
wrote:
This has been discussed before, not sure what the conclusion was (if any)
http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
http://www.mail-archive.com/public-webapps@w3
This has been discussed before, not sure what the conclusion was (if any)
http://www.mail-archive.com/public-webapps@w3.org/msg06137.html
http://www.mail-archive.com/public-webapps@w3.org/msg06345.htmlsnip
In order for the URN to be useful, it would have to have a mediaType
associated with it,
Instead of calling back on success only, maybe call back on completion
regardless of success or failure. This way the caller would know when the
potentially lengthy operation was done, regardless of the outcome.
2010/3/11 Dumitru Daniliuc d...@chromium.org
joao,
it looks like we mostly agree
Horray for FormData! My $0.02
* UTF8 always
* Sending initiates the POST of a snapshot of the FormData at the time send
is called, subsequent modifications to the FormData don't affect what is
asyncly being sent, but do affect subsequent sends of the modified FormData.
* XHR.send(formData)
On Thu, Jan 21, 2010 at 12:49 PM, Jonas Sicking jo...@sicking.cc wrote:
One thing to remember here is that if we require snapshotting, that
will mean paying potentially very high costs every time the
snapshotting operation is used. Potetially copying hundreds of
megabytes of data (think
Web-Indexed-Storage
On Mon, Nov 30, 2009 at 4:52 PM, Nikunj R. Mehta nikunj.me...@oracle.comwrote:
On Nov 30, 2009, at 3:14 PM, Michael(tm) Smith wrote:
Jeremy Orlow jor...@chromium.org, 2009-11-30 14:46 -0800:
I agree with Mike, but I'd also note that Web Key-Value Database could
9, 2009 at 10:09 AM, Alexey Proskuryakov a...@webkit.org wrote:
07.11.2009, в 10:47, Michael Nordman написал(а):
I've been wondering if SharedWorkers should have a means of establishing
an appcache similar to how pages can via the html manifest='x' mechanism.
My mental model
I've been wondering if SharedWorkers should have a means of establishing an
appcache similar to how pages can via the html manifest='x' mechanism.
My mental model is that a shared worker is very much like a top-level page
with respect to appcaches, but that means for a shared worker to
the third argument to the constructor would always be the manifest
URL).
-atw
On Sat, Nov 7, 2009 at 10:47 AM, Michael Nordman micha...@google.comwrote:
I've been wondering if SharedWorkers should have a means of establishing
an appcache similar to how pages can via the html manifest='x' mechanism
On Sat, Oct 24, 2009 at 9:37 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 24 Oct 2009, Michael Nordman wrote:
On Fri, Oct 23, 2009 at 8:45 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 23 Oct 2009, Michael Nordman wrote:
An area that may be worth exploring, that would add to the list
On Fri, Oct 23, 2009 at 8:45 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 23 Oct 2009, Michael Nordman wrote:
An area that may be worth exploring, that would add to the list things
that go beyond syntactic sugar, could be for multiple documents to
listen in on the same event-stream
On Fri, Oct 23, 2009 at 3:21 PM, Maciej Stachowiak m...@apple.com wrote:
On Oct 23, 2009, at 1:44 PM, Jonas Sicking wrote:
I also continue to miss actual developer demand for server sent
events. Seems like it doesn't add a lot of sugar over simply using
XMLHttpRequest and progress events.
This particular proposal is clearly a good feature and Bjoern's is a good
articulation of privacy concerns.
Something lacking in the web platform in general (to my knowledge, albeit
limited) is a permissioning scheme whereby sites or applications can
establish rights. Is there any work being done
What I think we really want is a script-only means of sending multipart
form-data encoding POSTs that contain a mix of file- parts and binary-parts
(in addition to the ability to send the raw contents of a file).
* script-only, so these POSTs can be performed in workers
* multipart form-data, its
On Mon, Sep 14, 2009 at 1:26 PM, Jonas Sicking jo...@sicking.cc wrote:
2009/9/14 Michael Nordman micha...@google.com:
What I think we really want is a script-only means of sending multipart
form-data encoding POSTs that contain a mix of file- parts and
binary-parts
(in addition
Try this link instead...http://dev.w3.org/2006/webapi/WebSimpleDatabase/
Nikunj's link actually points to http://dev.w3.org/2006/webapi/DataCache/ which
is also interesting, but seemingly not what was intended.
@Nikunj, I have not yet read thru your draft in detail, but will do so. In
principle,
If the version is stored in the database file itself, as is with webkit's
impl for example, the database object does not have immediate access to that
value.
On Thu, Sep 3, 2009 at 5:57 PM, João Eiras jo...@opera.com wrote:
Hi!
Database.changeVersion expects oldVersion and newVersion
1.
Open a new SQL transaction to the database, and create a
SQLTransactionhttp://dev.w3.org/html5/webdatabase/#sqltransaction
object
that represents that transaction. If the *mode* is read/write, the
transaction must have an exclusive write lock over the entire database. If
the
Currently we have File and FileData, where a File object ISA FileData
object... completion is delivered via readXXX method completion callbacks.
It would be easy to add progress callbacks to those readXXX methods.
I think Garrets point about two different corners of the webapp issuing
reads
interface Window {
readonly attribute Timing
http://www.corp.google.com/~zhihengw/no_crawl/html5/timing.html#timing-0
pageTiming;
};
The pageTiming attribute represents the timing information related to the
current top-level browsing context. Each top-level browser context must have
a
On Thu, Aug 6, 2009 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com wrote:
Thanks for the update to the draft! Below some feedback:
In the table of contents the link to the filedata URL scheme is broken.
The Web IDL
agreed... slice() seems more appropiate
On Wed, Aug 5, 2009 at 10:34 PM, Adam de Boor adeb...@google.com wrote:
this is a minor point, but I'm finding the name of the splice method to
be odd. To me splice means to join, and slice would seem a more
appropriate name. The Array object has both
On Fri, Aug 7, 2009 at 3:21 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 7, 2009 at 12:23 PM, Michael Nordmanmicha...@google.com
wrote:
I think getAsURL() should become an attribute instead. E.g.
readonly attribute DOMString localURL;
Since it is just a reference there
This is very encouraging. It sounds like we agree in principal that the best
place for the features represented in the DataCache proposal are extensions
to the AppCache corner of the world.
My preference would be to keep the official AppCache spec stable right now,
but to begin designing those
On Wed, Jul 22, 2009 at 4:44 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 22 Jul 2009 04:07:18 +0200, Arun Ranganathan a...@mozilla.com
wrote:
This still sends strings, but XHR 2[2] has got:
void send(in ByteArray data);
which makes me think we need a binary getter as well
http://code.google.com/apis/gears/api_blobbuilder.html
This I'm less sanguine about, since the immediately desired capability is
to work with existing system files.
The motivating usecase for this feature in Gears is to compose the body of a
POST in the multipart/form-data format, including
Ranganathan a...@mozilla.com wrote:
Michael Nordman wrote:
http://code.google.com/apis/gears/api_blobbuilder.html
This I'm less sanguine about, since the immediately desired capability
is
to work with existing system files.
The motivating usecase for this feature in Gears is to compose
On Tue, Jul 21, 2009 at 6:20 PM, Arun Ranganathan a...@mozilla.com wrote:
Michael Nordman wrote:
The BlobBuilder.append() method is central to the use-case I'm referring
to.
builder.append(string data that comprises the multipart/form-data header);
builder.append(string data that comprises
On Wed, Jul 22, 2009 at 4:00 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 21, 2009, at 11:25 PM, Nikunj R. Mehta wrote:
On Jul 21, 2009, at 9:15 PM, Adrian Bateman wrote:
While it might not be the perfect solution (we know the web far from
ideal and is a lot of compromise), this
81 matches
Mail list logo
