[XHR2] Streamed send or receive
I'd like to hear from the WG if the following use cases or issues have been discussed before. 1) When onreadystatechange is invoked as new response data is being received, currently there is no way to clear any buffered responseText (alike) that has already been consumed. The lack of such a capability will force the server to disconnect to avoid memory overflow on the client-side, e.g. when the server is streaming a large volume of text or binary data to the client. An example API to solve the above problem could be: XMLHttpRequest.removeResponseText(); // return and clear any buffered response data 2) Currently, request body has to be sent all at once. This is not desirable when request data is computed from a streamed data source or from user input. The lack of a programmatic way to send partial request data (as it is being generated) will force the application to send multiple XHR requests. Worse yet, it actually breaks the REST semantics of the target resource that processes the entire POST body. A simple API to solve this problem may look like: XMLHttpRequest.sendPartialReply(data); - Wenbo
Re: [XHR2] Streamed send or receive
Sorry, the API for 2) should read: SendPartialRequest(). On Thu, Oct 6, 2011 at 12:57 AM, Wenbo Zhu wen...@google.com wrote: I'd like to hear from the WG if the following use cases or issues have been discussed before. 1) When onreadystatechange is invoked as new response data is being received, currently there is no way to clear any buffered responseText (alike) that has already been consumed. The lack of such a capability will force the server to disconnect to avoid memory overflow on the client-side, e.g. when the server is streaming a large volume of text or binary data to the client. An example API to solve the above problem could be: XMLHttpRequest.removeResponseText(); // return and clear any buffered response data 2) Currently, request body has to be sent all at once. This is not desirable when request data is computed from a streamed data source or from user input. The lack of a programmatic way to send partial request data (as it is being generated) will force the application to send multiple XHR requests. Worse yet, it actually breaks the REST semantics of the target resource that processes the entire POST body. A simple API to solve this problem may look like: XMLHttpRequest.sendPartialRequest(data); - Wenbo
Re: XBL2 is dead.
On Mon, Sep 26, 2011 at 8:28 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 22 Sep 2011 20:30:24 +0200, Dimitri Glazkov dglaz...@chromium.org
wrote:
Further, instead of packaging Web Components into one omnibus
offering, we will likely end up with several free-standing specs or
spec addendums:
1) Shadow DOM, the largest bag of with XBL2's donated organs --
probably its own spec;
2) Constructible and extensible DOM objects which should probably
just be part of DOM Core and HTML;
3) Declarative syntax for gluing the first 2 parts together -- HTML
spec seems like a good fit; and
4) Confinement primitives, which is platformization of the lessons
learned from Caja (http://code.google.com/p/google-caja/), integrated
with element registration.
It's still not very clear to me what any of this means and how it will fit
together.
While Dimitri works on the wiki version (pending his vacation), let me
lay them out in a slightly different order (2, 3, 1, 4):
- Today's DOM is actively hostile to idiomatic use in JavaScript. The
current WebIDL draft fixes some of this (yay for real prototypes!) but
not all. What we're suggesting is that, at least for HTML, we should
close the circuit on this as a matter of hygiene if nothing else.
Practically speaking, that means: giving HTML element types *real*
constructors (e.g. today's new Image(), not just create* factories),
allowing them to be subclassed in the same idiomatic way everything
else in JS can, and giving them meaningful prototypes (handled by
WebIDL). Combined, these give us a way to think about building new
elements but without any connection to markup. They're just new JS
types that just happen to be DOM nodes. The fact that we think of them
differently today is *A BUG*, and one that we can fix. Best of all,
this is exactly the sort of thing that UI libraries like JQuery UI,
Dojo, Closure, YUI, etc, etc. do all day long but without
infrastructure to *really* participate in DOM.
- Declarative syntax is sugar that makes all this programmatic stuff
amenable to tooling and web developers who are more comfortable with
HTML than JS
- Once we've got custom element types, it sure would be handy to be
able to hide away your UI implementation. Shadow DOM, a concept
cribbed from XBL and friends, can provide this. Once you can have a
scriptable shadow which hides its elements away from regular
traversal, your element's API becomes more useful since your guts
aren't spilling out for the world to view. We've already refactored
many WebKit internal element implementations to use Shadow DOM to
great effect, so the value is clear. Exposing it to content authors is
the next obvious step.
- Describing all of what happens above in terms of the fewest number
of primitive APIs keeps us honest. Small, orthogonal APIs instead of
one monolithic thing help us drive consistency through the platform.
The less that's described as spec magic, the more we have to lean on
the generative composition of things web developers already know. For
instance, being able to subclass plain old JS types from DOM makes
it possible to define all of this stuff as though you'd just written
out something like:
function MyElementType(attrs) {
HTMLElement.call(this); // superclass ctor call, needed for
mixin properties
this.shadow = new ShadowRoot(this); // not magic, just new-ing
up this element's shadow root
// custom ctor behavior here
}
// delegate to the plain-old prototype chain.
MyElementType.prototype = Object.create(HTMLElement.prototype, { ... });
This might not look right to a spec author's eyes, but trust me, this
is how idiomatic JS subclassing of DOM *should* look. A version of
this component model built out of small primitives allows us to make
DOM work with it's environment, not against it, a principle that I
think should be a primary goal in all of our designs.
Having either a specification or examples to shoot at would be
helpful. Once it is more clear what each of these parts is going to look
like, it might be easier for me to comment on how you suggest we split them.
Why split it like this? Several reasons:
a) they are independently moving parts. For example, just shadow DOM,
all by itself, is already a useful tool in the hands of Web
developers. It's our job as spec developers to ensure that these bits
comprise a coherent whole, but from implementation perspective, they
don't need to block one another.
How do you construct a shadow DOM though declaratively without a component?
b) each belongs in the right place. For example, making DOM objects
extensible is a concern inside of the DOM Core spec. Declarative
syntax really needs to live in HTML. Also...
c) some parts are too small to be their own spec.
Constructible/extensible DOM objects bit does not even have an API
surface.
d) And finally, every bit has potential of solving problems that are
more general than just about components. We shouldn't
[Bug 14395] New: asd asasd asda dasd as d
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14395 Summary: asd asasd asda dasd as d Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: asd asasd asda dasd as d Posted from: 194.47.167.58 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1 -- Configure bugmail: http://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 14396] New: ddfsdfsdf sdf fdsgshdf vjlh fjhvkjds hkjdfh jdsgfvslhjfdvhd
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14396 Summary: ddfsdfsdf sdf fdsgshdf vjlh fjhvkjds hkjdfh jdsgfvslhjfdvhd Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: ddfsdfsdf sdf fdsgshdf vjlh fjhvkjds hkjdfh jdsgfvslhjfdvhd Posted from: 91.199.92.82 User agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.187 Safari/535.1 -- Configure bugmail: http://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: Joint meeting of the CSS/WebApps/WebFonts WGs
[ + WebAppSec WG ] I included the WebAppSec WG since CORS is now a joint deliverable of WebApps and WebAppSec. (CORS is generically named Secure Cross-Domain Resource Sharing in their charter [1].) If we are going to have a joint meeting, I have a strong preference for October 31. WebApps currently has some open time slots that day: http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31 I just allocated the 11:00-12:00 slot for this topic and if that doesn't work for others, please propose (as soon as possible) an alternate time that day. In the meantime, if there are any related technical issues, please use public-webapps (I don't think there is need for a bunch of cross-posting). -Art Barstow [1] http://www.w3.org/2011/08/appsecwg-charter.html#deliverables On 10/5/11 3:36 PM, ext Levantovsky, Vladimir wrote: Dear WG Chairs, W3C Staff contacts and WG members, The WebFonts WG has recently published WOFF specification as W3C Candidate Recommendation. The specification flags two features as “at risk”, both of them related to font loading behavior with default same-origin restriction and CORS as a mechanism to relax it when needed. The WebFonts WG believes that these features are best to be specified as part of the CSS3 Fonts module that defines font loading behavior. The most recent version of CSS3 Fonts WD contains section 4.8 that provides for default same-origin restriction and CORS, but they are also marked as “at risk” pending the resolution on the recent proposal to specify “From-Origin” HTTP header as an alternative mechanism to control the resource loading on the Web. I would like to respectfully ask the chairs and the members of the CSS and WebApps working groups to allocate a time during the W3C TPAC week for a joint meeting with WebFonts WG to discuss the mechanisms for access control (CORS) and resource loading (From-Origin) to be able to determine the way forward and resolve the features at risk that are now parts of the CSS3 Fonts and WOFF specifications. Thank you. On behalf of the WebFonts WG, Vladimir Levantovsky, WebFonts WG chair
Re: Generic guide to exceptions, events, etc. for new APIs Re: [indexeddb] New WebIDL Exception Model for IndexedDB
On Monday, October 3, 2011 at 11:43 PM, Arun Ranganathan wrote: (generally speaking...) Seems there is a lot of confusion about how to do this properly (and I'm seeing that this is going to now be an issue amongst a number of groups, including this group, DAP, and even other organisations that are trying their best to define new APIs such as Webinos and WAC). Perhaps the best thing to do would be to create a wiki page that defines how to do this using some very generic examples. What would be great would be to see how the prose maps to the IDL and how the IDL maps to a real object in Java script… and also show how the DOM4 spec takes care of setting the code and the message…. so, a Exceptions and events for [Spec Writing] Dummies would be greatly appreciated (and will avoid a few common mistakes). I agree, and admit to confusion on my part here as well. I'm keen that errors and exceptions are spec'd consistently across the platform. We're now contemplating eliminating things that we once took for granted (for example, having a dedicated exception such as FileException, etc.). Robin took the initiative to create a skeleton: http://test.w3.org/webapps/api-design/ Maybe we can do a quick breakout session with Anne and anyone else interested during TPAC and fill it in. We just need quick bullet points and Robin and I can add examples etc. Kind regards, Marcos
Re: Generic guide to exceptions, events, etc. for new APIs Re: [indexeddb] New WebIDL Exception Model for IndexedDB
On 10/6/11 12:16 PM, ext Marcos Caceres wrote: On Monday, October 3, 2011 at 11:43 PM, Arun Ranganathan wrote: (generally speaking...) Seems there is a lot of confusion about how to do this properly (and I'm seeing that this is going to now be an issue amongst a number of groups, including this group, DAP, and even other organisations that are trying their best to define new APIs such as Webinos and WAC). Perhaps the best thing to do would be to create a wiki page that defines how to do this using some very generic examples. What would be great would be to see how the prose maps to the IDL and how the IDL maps to a real object in Java script… and also show how the DOM4 spec takes care of setting the code and the message…. so, a Exceptions and events for [Spec Writing] Dummies would be greatly appreciated (and will avoid a few common mistakes). I agree, and admit to confusion on my part here as well. I'm keen that errors and exceptions are spec'd consistently across the platform. We're now contemplating eliminating things that we once took for granted (for example, having a dedicated exception such as FileException, etc.). Robin took the initiative to create a skeleton: http://test.w3.org/webapps/api-design/ Maybe we can do a quick breakout session with Anne and anyone else interested during TPAC and fill it in. We just need quick bullet points and Robin and I can add examples etc. FYI, I added it to WebApps' Potential Topics list http://www.w3.org/2008/webapps/wiki/TPAC2011#Potential_Topics.
RE: [indexeddb] Implicit Transaction Request associated with failed transactions
On Tuesday, October 04, 2011 3:01 AM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 7:59 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Sep 12, 2011 at 2:53 PM, Israel Hilerio
isra...@microsoft.com
wrote:
Based on previous conversations, it seems we've agreed that there
are
situations in which a transaction could failed independent of explicit
requests (i.e. QUOTA_ERR, TIMEOUT_ERR). We believe that this can be
represented as an implicit request that is being triggered by a
transaction. We would like to add this concept to the spec. The
benefit of doing this is that it will allow developers to detect the
error code associated with a direct transaction failure. This is how we see
the concept being used:
trans.onerror = function (e) {
//eventTarget is mapped to an implicit transaction that was created
behind the scenes to track the transaction
if (e.eventTarget.errorCode === TIMEOUT_ERR) {
// you know the transaction error because of a timeout problem
}
else if (e.eventTarget.errorCode === TIMEOUT_ERR) {
// you know the transaction error because of a quota problem
}
}
Our assumption is that the error came not from an explicit request
but
from the transaction itself. The way it is today, the e.eventTarget
will not exists (will be undefined) because the error was not
generated from an explicit request. Today, eventTargets are only
populated from explicit requests.
Good catch!
We had a long thread about this a while back with the subject
[IndexedDB] Reason for aborting transactions. But it seems to have
fizzled with no real conclusion as to changing the spec. In part
that seems to have been my fault pushing back at exposing the reason
for a aborted transaction.
I think I was wrong :-)
I think I would prefer adding a .errorCode on IDBTransaction through
(or .errorName or .error or whatever we'll end up changing it to).
This seems more clear than creating a implicit request object. It'll
also make it easy to find the error if you're outside the error
handler. With the implicit request, you have no way of getting to
the request, and thus the error code, from code outside the error
handler, such from code that looks at the transaction after it has run.
And the code above would work exactly as is!
Let me know what you think?
In detail, here is what I suggest:
1. Add a .errorCode (or .errorName/.error) property on
IDBTransaction/IDBTransactionSync.
2. The property default to 0 (or empty string/null) 3. In the Steps
for aborting a transaction add a new step between the current steps 1
and 2 which says something like set the errorCode property of
vartransaction/var to varcode/var.
This way the reason for the abort is available (through the
transaction) while firing the error event on all still pending
requests in step 2. The reason is also available while firing the
abort event on the transaction itself.
/ Jonas
Independent on how we handler error, we like this approach! This is our
interpretation of the impact it will have on the overall feature.
SCENARIO #1:
Whenever there is an error on a request, the error value associated with the
request will be assigned to the transaction error value.
The error value in the transaction will be available on the
IDBTransaction.onerror and IDBTransaction.onabort handlers.
SCENARIO #2:
Whenever there is an error associated with the transaction (e.g. QUOTA or
TIMEOUT ), the error value associated with the failure (e.g. QUOTA or TIMEOUT)
will be assigned to the transaction error value. The error value in the
transaction will be available on the IDBTransaction.onerror and
IDBTransaction.onabort handlers.
SCENARIO #3:
A developer uses the IDBTransaction.abort() method to cancel the transaction.
No error will be assigned to the transaction error value. The error value will
be 0 (or empty string/null) when the IDBTransaction.onabort handler is called.
SCENARIO #4 (to be complete):
Whenever there is an error on a request, the error value associated with the
request will be assigned to the transaction error value. However, if the
event.preventDefault() method is called on the request, the only handler that
will be called will be IDBTransaction.onerror and the error value will be
available in the transaction. This implies that the value of the first
transaction event error that is not cancelled or prevented from executing its
default behavior will be value that will be contained by the error on the
transaction when the IDBTransaction.onabort handler is called. See example
below:
request1 == fires onerror with event.target errorCode ==
DATA_ERR
//request1 will preventDefault on the error event
transaction == fires onerror with this.errorCode = event.target.errorCode ==
DATA_ERR
request2 == fires onerror with event.target errorCode ==
[Bug 13584] [web messaging] Channel Messaging Origins
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13584 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-06 22:44:37 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: see above --- Comment #4 from contribu...@whatwg.org 2011-10-06 22:44:40 UTC --- Checked in as WHATWG revision r6647. Check-in comment: include information about the capabilities model http://html5.org/tools/web-apps-tracker?from=6646to=6647 -- Configure bugmail: http://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 13584] [web messaging] Channel Messaging Origins
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13584 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-10-06 22:44:37 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: see diff given below Rationale: see above -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[IndexedDB] Passing an empty array to IDBDatabase.transaction
Hi All, In both the Firefox and the Chrome implementation you can pass an empty array to IDBDatabase.transaction in order to create a transaction which has a scope that covers all objectStores in the database. I.e. you can do something like: trans = db.transaction([]); trans.objectStore(any objectstore here); (Note that this is *not* a dynamic scoped transaction, it's still a static scope that covers the whole database). In other words, these implementations treat the following two lines as equivalent: trans = db.transaction([]); trans = db.transaction(db.objectStoreNames); This, however, is not specified behavior. According to the spec as it is now the transaction should be created with an empty scope. I suspect both Mozilla and Google implemented it this way because we had discussions about this syntax on the list. However apparently this syntax never made it into the spec. I don't recall why. I'm personally not a big fan of this syntax. My concern is that it makes it easier to create a widely scoped transaction which has less ability to run in parallel with other transactions, than to create a transaction with as narrow scope as possible. And passing db.objectStoreNames is always possible. What do people think we should do? Should we add this behavior to the spec? Or are implementations willing to remove it? / Jonas
