According to the spec, the send() method of XmlHttpRequest objects
enable an internal 'send()' flag showing that the request has been
done, and not allowing to do several requests on the same XHR object,
although the current API with an open() method leads to think that's
possible. Due to this, I
The send() flag is only set as long as the fetch is ongoing. Once the
fetch has finished, it is no longer set. So this is already possible.
I did some tests some months ago and I was not be able to achieve it,
nor found any info or examples on Internet about if it's or it's not
possible.
So,
You need to invoke open() to set the object in the proper state.
Ok, good trick (didn't know it, thanks :-) ), but I was asking about
with just one call to .open(), being able to call several times to
.send(). That's why I did the reference to KeepAlive header.
--
Si quieres viajar alrededor
Not to beat a dead horse, but would https://code.google.com/p/csharp-sqlite/
count as an independent implementation of the SQLite SQL syntax?
I don't understand: is it a port of SQLite to managed code, or is it a
reimplementation from scratch?
--
Si quieres viajar alrededor del mundo y ser
I found registerElement a good candidate and parallel to
registerProtocolHandler, but after this comments I also think
declareElement is a better alternative. +1 to it.
Send from my Samsung Galaxy Note II
El 13/12/2013 10:18, Dominic Cooney domin...@google.com escribió:
On Fri, Dec 13, 2013 at
Should have data: and blob: schemes the same consideration here?
2013/12/12 bugzi...@jessica.w3.org:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24074
Bug ID: 24074
Summary: new Worker('data:...') should not throw
Product: WebAppsWG
Version:
I have seen registerProtocolHandler() and it's being discused
registerServiceWorker(). I believe registerElementDefinition() or
registerCustomElement() could help to keep going on this path.
Send from my Samsung Galaxy Note II
El 11/12/2013 21:10, Edward O'Connor eocon...@apple.com escribió:
- Canvas in Workers
There's been various proposals, including one in the spec that hasn't
met with implementor approval; I'm waiting for something to get
traction amongst the competing proposals.
- Being clearer about what features are visible in workers
Blocked on:
11/12/2013 22:18, Ian Hickson i...@hixie.ch escribió:
On Wed, 11 Dec 2013, pira...@gmail.com wrote:
- Canvas in Workers
There's been various proposals, including one in the spec that
hasn't
met with implementor approval; I'm waiting for something to get
traction amongst
I totally agree, this is the kind of things I said several weeks ago
about why we shouldn't promote the development of sync APIs on
workers, and stick only with the same async APIs from the main thread.
2013/12/5 Charles Pritchard ch...@jumis.com:
On 12/4/13, 2:43 AM, Ke-Fong Lin wrote:
IMHO,
Why lastModifiedDate being a Date object is bad?
2013/12/2 Arun Ranganathan a...@mozilla.com:
Greetings public-webapps,
I'm interested in feedback from imlementors about the lastModifiedDate
attribute exposed on File objects. The latest draft of the File API spec.
describes an attribute
What's the purpose of the integer in the lastModified attribute?
Epoch time in (mili)seconds?
2013/11/28 bugzi...@jessica.w3.org:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23853
Arun a...@mozilla.com changed:
What|Removed |Added
Json manifest seems a nice solution to me :-)
Send from my Samsung Galaxy Note II
El 28/11/2013 07:21, eli elib...@gmail.com escribió:
The web is server + client sides. Trying to fix issues you have with
client technologies only (appcache, JavaScript, ...) will always be a
bad
choice.
The web is server + client sides. Trying to fix issues you have with
client technologies only (appcache, JavaScript, ...) will always be a bad
choice.
I disagree, Javascript and web browsers are becoming powerful enough
to delegate servers to their barebones, just offering storage or
databases
To be available offline, the device has to hit a server first, then the
appcache magic happens.
Obviously.
No reason the server couldn't prepare / select what to send to the device:
iOS won't support WebM anytime soon, there is no reason to constantly ask iOS
device the same info again
Why not attempt to give the browser-side manifest functionality
the ability to feature test for file support instead? Then the browsers
can be the trusted source instead of everyone having to create new divergent
browser file support inference hacks.
This seems to me that this is some kind of
1. I'm not advocating for full scriptability, just basic support detection,
e.g.:
`if accepts(audio/ogg) ...`
Some kind of basic scriptability like the one on CSS, isn't it? Ok, it's good.
The main problem I'd see there is if the browser also needs to know what
plugins
(or
I asked for this several months ago on the W3C public-WebRTC mail list (
https://groups.google.com/forum/m/#!msg/discuss-webrtc/1hnewM6xxf8/nzNg6tcxC6wJ),
and the final answer was that we should wait until the specification
was
more stable before going into more problems. Since now Chrome Firefox
Yes. I completely agree. Personally in my projects, I wish there was to
create custom filesystems backed by JavaScript code that are exported to
hierarchical URLs. It would work somewhat like server-side web development
where a js function handles the request for a file. This is basically
That's very interesting and useful, but I don't think it fits the same use
case I was talking about. I want the ability to create some object that
exports an URL that I can put in an iframe. Then all requests from that
iframe for resources will dynamically call my javascript code. I could
+1 to symbolic links, they have almost the same functionality that hard
links and are more secure and flexible (they are usually just plain text
files...).
El 30/10/2013 01:42, Brendan Eich bren...@mozilla.com escribió:
Hard links are peculiar to Unix filesystems. Not interoperable across all
functioning and hadn't considered
the implementation. My understanding is that the UA will map from the
filename to an actual file using some kind of database. My assumption was
the logical idea of a link would happen in that layer.
On Wed, Oct 30, 2013 at 1:14 AM, pira...@gmail.com pira
What you are asking for could be fixed with redirects, that it's the
HTTP equivalent of filesystems symbolic links :-)
2013/10/31 Brian Stell bst...@google.com:
In Request for feedback: Filesystem API [1] it says This filesystem would
be origin-specific.
This post discusses limited readonly
Look at IndexedDB API, since asynchronous one was enought dfor everybody,
synchronous one was not implemented by the browsers and now it has became
deprecated... :-)
Well regarding my position I would not smile ;-)
I was considering a server-side implementation of indexedDB. There is
Javascript now has support for yield statements the same way Python does,
that's a way to stop (ie. sleep) the execution of a script to allow another
to work and restart from there. It's not their main function, but allow to
create what's called greenlets, green threads, and that's how I seen sync
9:38 AM, pira...@gmail.com pira...@gmail.com wrote:
Javascript now has support for yield statements the same way Python does,
that's a way to stop (ie. sleep) the execution of a script to allow another
to work and restart from there. It's not their main function, but allow to
create what's
Demostration by example, thanks :-)
2013/10/13 David Rajchenbach-Teller dtel...@mozilla.com:
On 10/13/13 6:33 PM, pira...@gmail.com wrote:
Don't know, I only know behavior of Python yield statement, but
Javascript one was developed following it and I'm 90% secure it follows
the same behaviour
When I see discussion of any new/recent synchronous APIs for the Web
platform these days I pretty much take it they're implicitly intended just
for use with Workers. So I assume that's the context Jonas intended.
It's a safe assumption, but I think it's better to be asynchronous also on
Synchronous APIs are easier to use since it's how things have been done
since decades ago,
No, they're easier to use because they fit the model of linear human
thought more naturally. The idea that asynchronous APIs are just as good
and easy as synchronous APIs, and that people only disagree
* Enable compiling code that was written for other platforms to the
web. Specifically where such code uses synchronous APIs, but where we
for good reasons have chosen not to expose synchronous counterparts in
the web platform. The most obvious example here is synchronous
filesystem access
Could it be procesed someway instead?
El 02/10/2013 03:34, Kyle Huey m...@kylehuey.com escribió:
The File API specifies how to deal with fragment identifiers. It should
also specify what to do with the query string. Presumably it should be
ignored when looking up blob URIs.
- Kyle
Query can also be procesed by client-side javascript...
El 02/10/2013 07:25, Kyle Huey m...@kylehuey.com escribió:
Well the query string is meant for the server, so what would you do with
it?
- Kyle
On Wed, Oct 2, 2013 at 1:10 PM, pira...@gmail.com pira...@gmail.comwrote:
Could
the same thing. If
someone does iframe src=blob:foo?bar and the script inside that blob
looks at bar and does processing on it that's fine.
- Kyle
On Wed, Oct 2, 2013 at 1:31 PM, pira...@gmail.com pira...@gmail.comwrote:
Query can also be procesed by client-side javascript...
El 02/10
I agree with Marcos. Also, I thinks IndexedDB fits better as a
Javascript database working in a pure object oriented way. I don't
think WebSQL it's absolutely bad, relational databases usually are
easier to work with, but a NoSQL one can be more efficient. I would go
for improve IndexedDB and if
Are you saying it's possible to use 'data:' requests with XHR? What's
the sense for this? The data is already on the client...
2013/9/19 Hallvord Steen hst...@mozilla.com:
Hi,
I see Gecko fakes a Content-Length header (visible to
getAllResponseHeaders()) when you load a data: URL with XHR.
Ian, was it ever the intent that these methods affect the way Fetch
works? Either way, this could use some tightening up as the current
language is quite vague. I think we should only let them affect the
navigate algorithm. Either way, we should clarify where the URL
translation happens as
Maybe. We'd lose the symmetry with registerContentHandler() unless we
move its redirect-like logic to fetch as well, aside from the security
implications.
This would need more discussion. It would be useful to allow
registerContentHandler() also to be used inside img tags, but also I
don't
When using registerProtocolHandler method to register a custom
protocol, according to the spec it is required that the uri parameter
allow to do a GET operation or their equivalent (so maybe it would be
used with ftp instead of http URIs, for example). I have done some
tests setting this custom
When using registerProtocolHandler method to register a custom
protocol, according to the spec it is required that the uri parameter
allow to do a GET operation or their equivalent (so maybe it would be
used with ftp instead of http URIs, for example). I have done some
tests setting this
Finally, is there a good test suite? I can't seem to find anything in the
way of regression tests. I'll perhaps publish my own, if not.
+1, I've developed my own In-Memory implementation as a polyfill to
ignore a bug on Chrome regarding to files storage and I'm also
thinking about develop one
That were just the tests I was talking about, thanks :-) Unluckily it
seems they are not prepared to just give them to your IndexedDB
implementation and run them all at once, but it's a good starting
point.
2013/7/30 Arthur Barstow art.bars...@nokia.com:
On 7/30/13 4:37 AM, ext pira...@gmail.com
Hell yes!!! +1000 to add an interface to inotify :-D
I'm concerned that you're taking this API too far. What's next -
mmaping a file to a byte array?
It would be cool... :-P
Ok, let's get serious. Maybe inotify would be too high level API and I
agree it would be moved to a later version,
Adding something like inotify would also enable use cases like having
a worker synchronize a filesystem to a server. Other parts of the
application could simply access the filesystem directly and do
whatever modifications it wants. Those notifications will
automatically be noticed and
I always found Widgets (in the MacOS X Dashboard way) as a sort of
self-contained web apps... :-)
2013/7/19 Daniel Buchner dan...@mozilla.com:
As some of you are aware, a widget spec or two
(http://www.w3.org/TR/2012/PR-widgets-apis-20120522/) have been floating
around for a while. These were
It make sense... also version could be calculated automatically each time
scheme is changed or with a latestModified timestamp...
El 17/07/2013 22:09, Mahon mbbald...@gmail.com escribió:
I am wondering why versions are required in the IndexedDB specification.
If I'm reading the specification
Having the full path within the filesystem removes some of the
security benefit of not allowing .., doesn't it?
There's no problem if it's just an implementation detail.
Conversely, is the
path useful if you can't use it to manipulate anything above the
current dir in the tree?
It's useful
I agree, the available libraries that currently exists not only are
slow compared to native code (I don't know of anyone that use the
trick used on the demos scene of canvas.getasbytestring() ) and to
speed up things they use webworkers, so they are difficult to use from
file:// scheme pages.
The most usual scenario I can foresee is an application server sending the
notifications to the web app instance(s). In any case nothing precludes that
a server-less webapp acts as an app server and sends notification to the Push
Server for delivery to other instances of the webapp.
Good
Seems it still make a distintion between Push Server and Application
Server. Wouldn't a webapp send some data to a Push Server so it gets
distributed on all the registered instances without needing to deploy
a custom Application Server? For server-less webapps this can be a
problem... :-/ Also, is
When this would be spected to be implemented on browsers? Any knows of at
least partial implementation except the mdv polyfill?
El 14/06/2013 15:18, Arthur Barstow art.bars...@nokia.com escribió:
On 6/14/13 9:02 AM, ext Robin Berjon wrote:
On 11/06/2013 17:59 , Anne van Kesteren wrote:
On
When this would be spected to be implemented on browsers?
Well, I think that's a bit of a loaded question and some could argue
http://www.w3.org/html/wg/drafts/html/master/templating.html provides a
sufficient specification for implementation.
I've only read the polyfill docs and seems very
Sorry to answer so late, busy with exams.
Then Chrome is taking REALLY liberally the interpretation, because on
some tests I removed the file and instead of raising an error it just
gave me an empty content and null modifiedTime and lenght...
That sounds more like a simple bug/incomplete
Actually, the response in [2] says that we should clarify in the spec
that files, blobs and filelists are stored by value rather than by
reference. This is not a normative change since the spec already
defines this behavior. However the behavior is defined somewhat
indirectly which means that
must implement it, just what the behavior is.
(Also, I didn't see your suggestion until I'd made the edit.)
Is that changed text is sufficient?
On Wed, Jun 12, 2013 at 3:01 AM, pira...@gmail.com pira...@gmail.com
wrote:
Actually, the response in [2] says that we should clarify in the spec
It was suggested that the current behavior in browsers was incorrect; that
the File should become inaccessible if/when it changes.
As I put on another thread, if an app want a particular version of a
file (a snapshoot) it should copy and/or upload it, and if it want a
live file, just keep the
We didn't come to much of a resolution.
It was suggested that the current behavior in browsers was incorrect; that
the File should become inaccessible if/when it changes.
bryan I disagree, the fact that re-accessing a file object loads the
latest version of the file is a valuable feature
The File API spec does allow browsers to store File by reference.
I thought so... that's the reason I was surprised when readed about
implementors where doing otherwise and in fact didn't found anything
about it on the spec.
Note that there's one limitation to keep in mind. File is meant to
The File API spec does allow browsers to store File by reference.
I thought so... that's the reason I was surprised when readed about
implementors where doing otherwise and in fact didn't found anything
about it on the spec.
Note that by reference means store a pointer to the original
According to IndexedDB specification, File and Blob and FileList objects
should be allowed to be stored inside IndexedDB doing a shallow copy. On
Mozilla this is possible, although File and Blob objects are stored
nativelly on a special place on the hard disk. Chrome is working on it at
this
Currently there's no way to fetch real time filesystem modifications inside
webapps, both on FileLists or DirEntries. I propose to add filesystem
monitoring events to the DirEntries objects, so when a file or directory is
added, removed or modified a corresponding event would buble on the
and length are null on Chrome to detect when a file has
been (re)moved, but what happens when a file is added? How can I be able to
detect it? I'm specially interested on this use case.
El 29/05/2013 19:51, Charles Pritchard ch...@jumis.com escribió:
On 5/29/2013 10:26 AM, pira...@gmail.com wrote
+1 to be able to use easily the default API without requiring third party
libraries.
Sent from my Android cell phone, please forgive the lack of format on the
text, and my fat thumbs :-P
El 07/03/2013 21:30, Shwetank Dixit shweta...@opera.com escribió:
On Thu, 07 Mar 2013 13:01:20 +0100, Alex
I have read this complains to the API before and I have to admit that
it doesn't seems difficult to me too, but the fact is that I'm
studying a computers degree and also have worked before with AppEngine
storage... :-P But I must to admit that the IndexedDB primitives are
too primitives and would
One solution would be to don't call directly to IndexedDB methods but
instead use custom wrappers that fit better with your application
(this is what I'm doing), but definitelly I totally agree with you
that IndexedDB should raise events when a row has been
inserted/updated/deleted. I think it was
track of a change sequence in each tab
This would be a welcome addition to the spec (after we get to enumerate
databases) :)
On 5 February 2013 21:59, pira...@gmail.com pira...@gmail.com wrote:
One solution would be to don't call directly to IndexedDB methods but
instead use custom wrappers
...@gmail.com pira...@gmail.com wrote:
Why it can propagate over tabs if all of them are accessing to the
same database?
2013/2/5 Dale Harvey d...@arandomurl.com:
The problem with emitting change notification on writes is that they
dont
propogate across tabs, my library has to use localstorage
Really nice usability, Ian :-)
2013/2/4 Ian Hickson i...@hixie.ch:
On Thu, 31 Jan 2013, Florian Bösch wrote:
There is a problem confronting applications desiring to use a variety of
APIs such as pointerlock, fullscreen, WebRTC, local storage and so on.
The problem is that each instance of
Hi Jack. Here we are both profesionals, volunteers and mainly
profesionals volunteering. W3C and WhatWG are not companies but only
places where anybody can add propositions and discuss them, but here
nobody get money (directly) from work here. Me, for example, I'm just
an student.
I can
, but it's not mandatory).
P.D.: yes, AppCache seems to fix my problem about dissapearing domains
(I need to test it) but it doesn't go to the heart of the problem...
2013/1/16 pira...@gmail.com pira...@gmail.com:
Good point. You are right about the fact if you a server somewhere it's
fairly
the lack of format on the
text, and my fat thumbs :-P
El 16/01/2013 13:34, Kyle Huey m...@kylehuey.com escribió:
On Tue, Jan 15, 2013 at 3:57 PM, pira...@gmail.com pira...@gmail.comwrote:
Ideas? Doubts? Comments? :-)
The use case here is not compelling enough for this amount of complexity
for all the objects on the webpage, and it
wouldn't be incompatible with my idea allowing a more fine-grained access
permissions, so they would be complementary.
Ideas? Doubts? Comments? :-)
2013/1/9 pira...@gmail.com pira...@gmail.com
Perhaps what we need (and I am ducking as I say
Perhaps what we need (and I am ducking as I say this) is a meta tag for
web pages, e.g.
meta name=previously-known-as content=http://olddomain.com:80;
or
meta name=same-as content=http://olddomain.com:80;
** **
This could then be used by the browser to allow the
Combarro.
Jesús Leganés Combarro
pira...@gmail.com
http://github.com/piranna/ShareIt
--
Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix.
– Linus Tordvals, creador del sistema operativo Linux
it with
your browser.
On Jan 8, 2013, at 7:08 AM, pira...@gmail.com wrote:
I have been looking on Internet and reading the spec but didn't be able to
get at answer.
Let's see the next situation: I've developed a webapp that use IndexedDB
to store personal data. It's pure client-side and server-less
74 matches
Mail list logo
