Re: [UndoManager] Re-introduce DOMTransaction interface?
I think we need to realize that a lot of the APIs that have been
designed in the past aren't terribly good APIs.
The IndexedDB API is rather new, and the manner in which it consistently
uses event handlers on returned objects is rather innovative. The
DOMTransaction object is more similar to that.
In other words, I think it's more important to focus on what makes a
good API, than what is consistent with other DOM APIs.
Consistency has its value. Even if some is lacking, fixing it in some
places and not in others might cause a jumble. Which is my feeling actually
about the IndexedDB API. Adding more syntactical variations can lead to
hectic code.
However, I agree that it's not the primary concern.
Something that I really liked about the old API was the fact that
using it created very intuitive code. Basically you just write a class
the way you normally would write a class, and then pass in your
object:
x = {
someState: 0,
apply: function() { this.someState++; this.modifyDOM(); },
unapply: function() { this.subState--; this.modifyDOMOtherWay(); },
...
};
undoManager.transact(x);
You can even do things like
undoManager.transact(createParagraphTransaction(params));
How's that different from:
function createParagrahTransaction(params) {
x = new DOMTransaction(Create paragraph);
x.apply = function() { ... use params... };
x.onundo = function() { ... use params ... };
return x;
}
Also, in your example, I think that in the JS-object proposal you won't be
able to reference the original object's properties -- it will be lost, and
'this' is window.
The fact that we have to choose between creating APIs that feel like
DOM APIs or JS APIs I think is an indication that DOM APIs are
doing things wrong. There should be no difference between DOM APIs
and JS APIs.
It is a problem. But WebIDL and JS aren't two of the same.
Re: [UndoManager] Re-introduce DOMTransaction interface?
On 07/12/2012 12:07 PM, Yuval Sadan wrote:
I think we need to realize that a lot of the APIs that have been
designed in the past aren't terribly good APIs.
The IndexedDB API is rather new, and the manner in which it consistently uses
event handlers on returned objects is rather innovative. The
DOMTransaction object is more similar to that.
In other words, I think it's more important to focus on what makes a
good API, than what is consistent with other DOM APIs.
Consistency has its value. Even if some is lacking, fixing it in some places
and not in others might cause a jumble. Which is my feeling actually
about the IndexedDB API. Adding more syntactical variations can lead to hectic
code.
However, I agree that it's not the primary concern.
Something that I really liked about the old API was the fact that
using it created very intuitive code. Basically you just write a class
the way you normally would write a class, and then pass in your
object:
x = {
someState: 0,
apply: function() { this.someState++; this.modifyDOM(); },
unapply: function() { this.subState--; this.modifyDOMOtherWay(); },
...
};
undoManager.transact(x);
You can even do things like
undoManager.transact(createParagraphTransaction(params));
How's that different from:
function createParagrahTransaction(params) {
x = new DOMTransaction(Create paragraph);
x.apply = function() { ... use params... };
x.onundo = function() { ... use params ... };
return x;
}
Also, in your example, I think that in the JS-object proposal you won't be able
to reference the original object's properties -- it will be lost, and
'this' is window.
'this' would be the object, not window when callback object is used.
The fact that we have to choose between creating APIs that feel like
DOM APIs or JS APIs I think is an indication that DOM APIs are
doing things wrong. There should be no difference between DOM APIs
and JS APIs.
It is a problem. But WebIDL and JS aren't two of the same.
[Bug 17757] New: Editorial: Add a note about why Blobs aren't Transferable
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17757 Summary: Editorial: Add a note about why Blobs aren't Transferable Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: File API AssignedTo: a...@mozilla.com ReportedBy: sim...@opera.com QAContact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org It would be nice to convey https://www.w3.org/Bugs/Public/show_bug.cgi?id=16952#c11 in a note in the spec, maybe somewhere near neutered since that's related. -- Configure bugmail: https://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 17758] New: Consider using microtasks for autorevoke
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17758 Summary: Consider using microtasks for autorevoke Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: File API AssignedTo: a...@mozilla.com ReportedBy: b...@pettay.fi QAContact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org Stable state is somewhat vague, since scripts can't really know when Blob URIs are auto-revoked. -- Configure bugmail: https://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: [Server-Sent Events] Network connection clarification
On Wed, 11 Jul 2012 00:52:06 +0200, Ian Hickson i...@hixie.ch wrote: On Tue, 10 Jul 2012, Kornel Lesi�~Dski wrote: However, I'm afraid that the most common implementation (aside from complete lack of error recovery) will be a simple as 30-second retry interval and that won't be very DoS-safe. UAs can do better than that. That's not entirely clear. It would seem below that you are providing reasons why UAs can do better than that, and better than individual authors (apart from the question of whether it is better to have a couple of dozen UAs write the code, or every app developer do so)... For example the spec could require UAs to have randomized retry interval and exponential backoff on failure. Is there anything more that authors could do client-side to avoid DoSing? Exponential back-off isn't at all necessarily the right solution. In particular, consider mobile devices, where network connectivity goes in and out as the user moves. Most of the time, you want to be trying to connect as soon as you have connectivity. Similarly with laptops on wifi where the connection is only briefly hurt by an obstacle -- you want to keep trying every few seconds until the obstacle is gone. Exponential backoff if a terrible thing in those kinds of situations. You can distinguish local network difficulties from server load difficulties in a variety of ways, e.g. having a dedicated ping server on the same network as the real server, which doesn't suffer from the same load concerns, and which you try to contact and only switch to exponential backoff if it responds but the main server isn't. And so on. UAs can do that kind of thing. SSE is mostly a convenience API (advanced authors can use streaming XHR or WebSockets to achieve the same result the hard way), so lack of convenience in error recovery feels like an omission in this API. If it's something we do want to eventually support, I think it's be something to consider for v2. I think it is something to consider as a bug in v1 - UAs can decide to fail eventually, but a single dropped connection seems like a poor reason to do so given the still somewhat flaky network we have around the world today. Living in Western European capitals with relatively good infrastructure, I find simple network dropout on fixed broadband networks far more common that something like entering a tunnel. cheers Chaals -- Chaals - standards declaimer
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On 7/11/12 7:52 PM, ext Ian Hickson wrote: On Wed, 11 Jul 2012, Julian Reschke wrote: OK; the amount of work is ~45 minutes (and probably can be automated for future publication cycles). See attachments; an edited version of the current editor's draft, and the diffs. ... ..and the diff was reversed; new version attached. Thanks, I do appreciate this patch Julian! Applying that diff to the spec on dev.w3.org I agree with Hixie that ideally the fix would apply to the original source rather than 1-off versions in dev.w3. However, if that isn't worked out, I will apply Julian's patch to the CR version. -Thanks, AB
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On 2012-07-12 13:47, Arthur Barstow wrote: On 7/11/12 7:52 PM, ext Ian Hickson wrote: On Wed, 11 Jul 2012, Julian Reschke wrote: OK; the amount of work is ~45 minutes (and probably can be automated for future publication cycles). See attachments; an edited version of the current editor's draft, and the diffs. ... ..and the diff was reversed; new version attached. Thanks, I do appreciate this patch Julian! Applying that diff to the spec on dev.w3.org I agree with Hixie that ideally the fix would apply to the original source rather than 1-off versions in dev.w3. However, if that isn't worked out, I will apply Julian's patch to the CR version. -Thanks, AB Sounds good. What do we do about the normative reference to a non-W3C-part of the WhatWG spec? (decoded as UTF-8, with error handling) Best regards, Julian
Re: [UndoManager] Re-introduce DOMTransaction interface?
'this' would be the object, not window when callback object is used. I was talking about what Ojan wrote: I was specifically talking about WebIDL Dictionaries. In which case, this.undo would set the undo property on the window. Why would you want to be able to set the undo function from the execut function? My whole point has been that we should not keep the actual object. on which, by the way, I also have to say: one of the nice things about the web is that the most interesting things sprout out of things being used out of context and beyond their purpose (am I quoting Einstein when I say that a problem cannot be solved using the same terms that were used to define it?). In this specific case, access to the object allows for context in the execute() call. This supports the notion, which you may discard of, of a module for actions that is separate from the UndoManager. Re using actions for several times, intuitively, an UndoManager can either throw an exception when an action is performed twice, or --the more elegant approach imo-- let an action be executed multiple times, and whatever would have applied to the single action (undo/redo behaviour) applies to each transaction. And if the author chooses to meddle with the undo/redo behaviour after execution, it's her responsibility. What applies to the operation is what is defined at the time the undo/redo occurs. Keep it simple. Yuval
Reminder: RfC: LCWD of Selectors API Level 1; deadline July 19
Original Message Subject:RfC: LCWD of Selectors API Level 1; deadline July 19 Resent-Date:Thu, 28 Jun 2012 14:59:09 + Resent-From:public-webapps@w3.org Date: Thu, 28 Jun 2012 10:58:36 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. -Thanks, AB
[Bug 17762] New: lastModifiedDate should not be nullable
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17762 Summary: lastModifiedDate should not be nullable Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: File API AssignedTo: a...@mozilla.com ReportedBy: a...@mozilla.com QAContact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org We should specify a non-null and arbitrary return value that is returned when the mdate cannnot be determined. Possible suggestions include arbitrary dates in the past that are unlikely. -- Configure bugmail: https://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: [File API] File behavior under modification
On Jul 11, 2012, at 10:02 PM, Glenn Maynard wrote: What's the main problem with it being nullable? A fabricated date seems strange, but instead of being nullable we could spec what the fabricated date is. I'm just not totally sure what the pros and cons are here. If you call d.getYear() and d is null, you get an exception, which has a very high chance of breaking the app if it's not checked for. Giving an arbitrary (but well-defined) default is much less likely to break things that badly. This is much more important when the null case is rare, because nobody is going to remember to test for it. Can you log a bug so that I can provide guidance for this in spec? Sorry, but to avoid rereading the thread, a bug for what exactly? Do you need anything beyond https://www.w3.org/Bugs/Public/show_bug.cgi?id=17746? Bug 17746 is for better definitions of snapshots. I minted Bug 17762 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=17762) to replace a nullable Date with something better. Strawperson suggestions welcome for what this arbitrary date should be, or else I may arbitrarily choose an unlikely Towel Day in the past (http://towelday.org/ -- don't panic). -- A*
Re: CfC: publish Candidate Recommendation of Web Sockets API; deadline July 18
On Thu, 12 Jul 2012, Julian Reschke wrote: It almost seems to me that nobody cares over here what the W3C document actually says, as there is that other more helpful version. In which case I wonder why it's published at all? Patent policy. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [UndoManager] Re-introduce DOMTransaction interface?
On Thu, Jul 12, 2012 at 2:07 AM, Yuval Sadan sadan.yu...@gmail.com wrote:
I think we need to realize that a lot of the APIs that have been
designed in the past aren't terribly good APIs.
The IndexedDB API is rather new, and the manner in which it consistently
uses event handlers on returned objects is rather innovative. The
DOMTransaction object is more similar to that.
In IndexedDB events work out ok since we can take advantage of the
event bubbling mechanism. That's not the case here.
Likewise, in IndexedDB you generally only have to install a single
event handler, which means that you can write code like:
store.get(...).onsuccess = function(event) { ... };
or
store.get(...).onsuccess = obj.myhandler.bind(obj);
Neither of which is possible here.
Yet, in IndexedDB I would have strongly preferred to use promices
rather than DOM-Events based Request objects. The only reason we don't
is because there are no standardized promices that we can use.
In other words, I think it's more important to focus on what makes a
good API, than what is consistent with other DOM APIs.
Consistency has its value. Even if some is lacking, fixing it in some places
and not in others might cause a jumble. Which is my feeling actually about
the IndexedDB API. Adding more syntactical variations can lead to hectic
code.
However, I agree that it's not the primary concern.
Indeed.
Something that I really liked about the old API was the fact that
using it created very intuitive code. Basically you just write a class
the way you normally would write a class, and then pass in your
object:
x = {
someState: 0,
apply: function() { this.someState++; this.modifyDOM(); },
unapply: function() { this.subState--; this.modifyDOMOtherWay(); },
...
};
undoManager.transact(x);
You can even do things like
undoManager.transact(createParagraphTransaction(params));
How's that different from:
function createParagrahTransaction(params) {
x = new DOMTransaction(Create paragraph);
x.apply = function() { ... use params... };
x.onundo = function() { ... use params ... };
return x;
}
Ah, you can, but that still doesn't give you nice class syntax.
What I actually meant to say was that you can't do something like:
undoManager.transact(new ParagraphTransaction(params));
Also, in your example, I think that in the JS-object proposal you won't be
able to reference the original object's properties -- it will be lost, and
'this' is window.
Only if you use a dictionary, which I don't think we should. We should
use an interface annotated with 'callback'.
The fact that we have to choose between creating APIs that feel like
DOM APIs or JS APIs I think is an indication that DOM APIs are
doing things wrong. There should be no difference between DOM APIs
and JS APIs.
It is a problem. But WebIDL and JS aren't two of the same.
I agree. I don't believe I was arguing that it was. All solutions
debated here can be described using WebIDL.
/ Jonas
[Bug 17765] New: APIs need to take a reference to blob data underlying object URLs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765
Summary: APIs need to take a reference to blob data underlying
object URLs
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: Windows NT
Status: NEW
Severity: normal
Priority: P2
Component: File API
AssignedTo: a...@mozilla.com
ReportedBy: gl...@zewt.org
QAContact: public-webapps-bugzi...@w3.org
CC: public-webapps@w3.org
This is the remaining portion of the autoRevoke blob URL feature. APIs that
take URLs and then operate on them asynchronously need to synchronously take a
reference to the underlying blob data before returning.
For example, when you say img.src = URL.createBlobURL(blob), the image fetch
doesn't necessarily begin immediately. It may not happen until well after the
script returns. Currently, that means that by the time the fetch begins, the
URL would no longer exist, because it's released as soon as the script returns.
To fix this, img.src = blobURL needs to take a reference to the underlying
blob data before the assignment returns. Then, all fetches that would normally
operate on the @src URL actually take place on the blob data.
For example, using XHR2 as an example, Associate blob data with *url* would
be added as a step after 6 (after resolving the URL). The associate blob data
with url algorithm would look up the Blob associated with the URL, and
associate the underlying data of that blob to it (or do nothing if it's not a
blob URL). That way, the blob data tags along with the URL when it's lter sent
to fetch (when send is called).
(In case this isn't clear, this is treating XHR2's url property as a
string-like object with a property hanging off it, and this wouldn't be visible
to scripts. It's essentially shorthand for passing a (url, blob) tuple to
fetch.)
As a side-effect, this also prevents img.src = URL.createObjectURL(blob);
blob.close(); from being nondeterministic. Currently, it depends on what
stage the image update was at.
One other note: all APIs should attempt to take this reference at the time the
URL enters the API (eg. when xhr.open is called), not at some later point (like
xhr.send). That is, this should still always work (for any API) without caring
if the caller gave you a blob URL:
function openURLLater(url)
{
xhr.open(url);
setTimeout(function() { xhr.send(); }, 1000);
}
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
