Overlap between StreamReader and FileReader -[Re: File API - Progress - Question about Partial Blob data]
Redirecting this thread to the overlap... thread because it is the same.
For Cyril -- I think the mistake is that XHR does provide incremental
data on 'loading' instead of delta data.
I have read again:
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html.
And still do not get it quite well, especially the presence of
eventtarget, as if for example the API was supposed to be able to
predict the end of a stream.
Again, I don't think that's the job of the API, its only job is to be
able to provide delta data, then the user implementation takes care of
the rest.
I read again too
https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm. This is
about the same as the File API.
Then I tried to figure out what would be the use of a Stream and came up
with the following examples:
var stream=new Stream();
document.getElementById('video').src=URL.createObjectURL(stream);
var ws=new WebSocket(xxx);
ws.onmessage=function(evt) {
stream.append(evt.data)
//or calculate the hash of the stream using delta data
//or encrypt the stream using delta data
//etc
};
or
var xhr_object = new XMLHttpRequest();
xhr_object.open(GET,yyy,true);
client.responseType=stream;
xhr_object.onreadystatechange=function() {
if (xhr_object.readyState===3) {
stream.append(this.deltaresponse);
//or same as above
};
};
xhr_object.send();
or
var pc = new RTCPeerConnection(xxx);
pc.onaddstream = function(evt){
stream.append(evt.stream);
//or same as above
}
//Stream to ArrayBuffer
var arraybuffer;
stream.readBinary().then(function(response) {
arraybuffer=response;
//we should be able here to read the stream per blocks of a given
size so we don't have to reslice the entire result to process it
//not sure how this can be speced with promises...
});
So unless there are some use cases that are not similar to the above
examples, maybe the Streams API should just be something like:
partial interface Blob {
PromiseArrayBuffer readBinary(BlobReadParams); (+block option)
PromiseDOMString readText(BlobReadTextParams); (+block option)
};
interface Stream : Blob {
PromiseStream append(ArrayBufferView or Stream or MediaStream or
Blob or ...);
};
and XHR is modified to add a property returning delta data.
Regards,
Aymeric
Le 05/09/2013 14:43, Cyril Concolato a écrit :
Hi all,
Le 29/08/2013 01:25, Aymeric Vitte a écrit :
The Streams API says for now This event handler should mimic the
|FileReader.onprogress|
http://dev.w3.org/2006/webapi/FileAPI/#dfn-onprogress event
handler
The second proposal is not very explicit for now but there is a read
resolver.
This discussion seems to be the same as the Overlap between
StreamReader and FileReader thread.
Now, I don't know what is the plan for the File API V2/Streams API
(Promises? Schedule?) probably I am missing some details but I don't
see what's the difficulty to replace the partial Blob as it is today
by delta data (both for Files and Streams), the API does not have to
care about non consumed data since the
reader/parser/whatever_handles_the_data takes care of it (as long as
delta data passed to the callback are not modified by the read, cf
the example I gave for the above thread)
I fully agree with Aymeric. Can someone summarizes what's the history
behind XHR that makes it hard to change (or better give an example
that would break)?
I would like to see progress on the Stream API (how can I help?)
because it solves one use case on which I'm working: download and
aggregation of resources via XHR and in parallel use of the
aggregation via a media element. This is similar to the MediaSource
approach but for simpler progressive download cases. This is a bit
different from the use cases I've seen on this list. The data is not
consumed by JavaScript calls but by the browser directly. The JS would
just use a series of StreamBuilder.append calls.
Cyril
Regards,
Aymeric
Le 27/08/2013 01:37, Kenneth Russell a écrit :
On Fri, Aug 23, 2013 at 8:35 AM, Arun Ranganathana...@mozilla.com
wrote:
On Aug 22, 2013, at 12:07 PM, Jonas Sicking wrote:
I think you might have misunderstood my initial comment.
I agree that the current partial data solution is not good. I
think we
should remove it.
I'd really like other implementors to weigh in before we remove
Partial Blob Data. Cc'ing folks who helped with it.
Eric Urhane asked me to follow up on this thread on behalf of Gregg
Tavares who unfortunately left Google.
The current spec for partial blob data is too inefficient, because it
accumulates all of the data since the beginning of the download. This
is not what's desired for streaming downloads of large data sets.
What's needed is a way to retrieve the data downloaded since the last
query. Several web developers have asked about this recently as
they're trying to stream ever larger 3D data sets into the browser.
I think we should instead create a better
[webcomponents]: The Shadow Cat in the Hat Edition
This progress update is brought to you in part by the Sith Order:
Sith: When The Light Side Just Ain't Cuttin' It.
Part 1: Revenge of the :host
Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
where we decided that shadow host could be matched by both outer and
inner trees
(http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html,
first point), we quickly coded this up in Blink and gave it to Mikey
...erm, the Polymer folks to chew on.
The folks spat out that morsel right across the table
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=22980), and presented
good arguments to justify their etiquette faux pas.
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them simply general combinators that opens shadow trees for
selector traversal, just like Element.shadowRoot did for DOM
traversal.
The brave guinea people became content and reverted to their natural
behaviors, but I then started worrying. Did I over-promise and finally
ruined encapsulation? When will our styling woes finally converge into
one solution?
Luckily, I have you, my glorious WebApp-erators. Put on your thinking
hats and help find one uniform solution. Something that fits well into
CSS, doesn't add too many new moving parts, and keeps the brave guinea
people at bay. That'll be the day.
:DG
Re: [webcomponents]: The Shadow Cat in the Hat Edition
I'm one of the guinea people, for whatever biases that gives me. Fwiw and
IMO, Dimitri summarized our thinking better than our own brains did.
finally ruined encapsulation?
As I see it the main Web Components system is based on soft encapsulation.
Each boundary is in force by default, but each one is also easily pierced
when needed.
E.g., shadow-roots are traversable, JS prototypes are mungeable (in
general). Ability to pierce CSS encapsulation (on purpose, doesn't happen
incidentally) allows us to do theming and other necessary customization
tasks without having to over-engineer.
It may be counter intuitive given the virtues of encapsulation, but IMO
this is a good design for a UI system.
As I understand there is work afoot to come up with (optional) 'sealed' or
'strongly encapsulated' components for other less laissez-faire uses. It
makes sense to me to have both extremes.
Scott
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov dglaz...@google.com wrote:
This progress update is brought to you in part by the Sith Order:
Sith: When The Light Side Just Ain't Cuttin' It.
Part 1: Revenge of the :host
Turns out, it's bad to be Super Man. After the Shadow DOM meetup,
where we decided that shadow host could be matched by both outer and
inner trees (
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0985.html,
first point), we quickly coded this up in Blink and gave it to Mikey
...erm, the Polymer folks to chew on.
The folks spat out that morsel right across the table
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=22980), and presented
good arguments to justify their etiquette faux pas.
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them simply general combinators that opens shadow trees for
selector traversal, just like Element.shadowRoot did for DOM
traversal.
The brave guinea people became content and reverted to their natural
behaviors, but I then started worrying. Did I over-promise and finally
ruined encapsulation? When will our styling woes finally converge into
one solution?
Luckily, I have you, my glorious WebApp-erators. Put on your thinking
hats and help find one uniform solution. Something that fits well into
CSS, doesn't add too many new moving parts, and keeps the brave guinea
people at bay. That'll be the day.
:DG
[Bug 23147] Describe File API Model
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23147 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Arun a...@mozilla.com --- Fixed: http://dev.w3.org/2006/webapi/FileAPI/#model -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23160] Add a File.rawName attribute on File alongside File.name, and parse for separators
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23160 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Arun a...@mozilla.com --- Fixed, but strictly along the lines of Comment 1. We're not doing File.rawName. -- You are receiving this mail because: You are on the CC list for the bug.
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov dglaz...@google.com wrote:
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Yeah, having the mere *presence* of a pseudo-class in a selector
change the set of elements the selector is matched against is a bad,
bad idea. It breaks an invariant in a confusing way, and prevents
easy refactoring of selectors.
The best way to do this is to introduce an at-rule that adds the host
element to the set of elements matched by the rules within it, perhaps
called @host. This was extraordinarily clumsy the first time we tried
to do it, but that was due to a host of other syntax issues that have
since been resolved. Now, just using @host to change the context, and
:host/:host() to select things, should work okay.
If we do this, should :host() still work in non-@host contexts? It
would match *any* element in the tree, if something in the ancestor
list, starting with the host element, matched the selector. Perhaps
it requires a different name now, to distinguish it from :host?
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
We talked about auto-surfacing the parts from contained components
previously. We decided not to do it, but we can address this at the
demand side by just introducing a second pseudo-element alongside
::part which selects amongst all the parts, including those of
contained components. No need to introduce new combinator syntax -
pseudo-elements are already combinators of a sort.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them simply general combinators that opens shadow trees for
selector traversal, just like Element.shadowRoot did for DOM
traversal.
You should be able to just do this with ::part as well. Note, though,
that this mixes up the questions of exposing a part for styling, and
exposing it for script-based manipulation. I was under the impression
that HTML elements that exposed a native shadow DOM would expose their
parts for styling, but were still black boxes for interaction
purposes. Has that changed?
On Mon, Sep 9, 2013 at 5:29 PM, Scott Miles sjmi...@google.com wrote:
finally ruined encapsulation?
As I see it the main Web Components system is based on soft encapsulation.
Each boundary is in force by default, but each one is also easily pierced
when needed.
E.g., shadow-roots are traversable, JS prototypes are mungeable (in
general). Ability to pierce CSS encapsulation (on purpose, doesn't happen
incidentally) allows us to do theming and other necessary customization
tasks without having to over-engineer.
I am okay with piercable boundaries, but I'm still concerned about the
pain that'll come from having *all* of your DOM exposed to all
Re: [webcomponents]: The Shadow Cat in the Hat Edition
since you have no clue what parts of your existing markup structure are
being depended on by others.
But we already have no clue. In all cases we are talking about guidelines.
You cannot outright prevent people from poking around in the guts of your
component.
In either case you can be assured that if users have followed the
guidelines (under our proposal, these would be explicit classes that you
publish for folks to use, instead of part names) they can upgrade
successfully.
I do see that there is a spectrum of foot-shooting here. It's just my
$0.02, but the 'ease of upgrading' argument is often used a bit bluntly.
I'd greatly prefer to stick with the current plan of having to mark things
to be exposed explicitly,
Fwiw, we tried that and got in the weeds right away. See Dimitri's post for
details. I'm afraid of trading real-life pain (e.g. exploding part lists)
for what is IMO an unreal advantage (e.g. the notion components can be
upgraded and assured never to break is just not realistic).
On Mon, Sep 9, 2013 at 5:52 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Sep 9, 2013 at 4:32 PM, Dimitri Glazkov dglaz...@google.com
wrote:
For what it's worth, it would be fairly easy to make shadow tree rules
match shadow host only when :host is present in a rule.
Unfortunately, this would leave Tab (and other CSS WG folks) in a sad
state, since addressing these arguments makes it harder to keep a
straight face with the concept of a pseudo class in regard to :host.
See discussion on bug for the gory details.
As of now, we are in that angsty state of not knowing what to do next.
Any ideas are appreciated. Note that there are some well-established
concepts in CSS and inventing fewer new concepts is much preferred.
Reuse, reduce, recycle.
Yeah, having the mere *presence* of a pseudo-class in a selector
change the set of elements the selector is matched against is a bad,
bad idea. It breaks an invariant in a confusing way, and prevents
easy refactoring of selectors.
The best way to do this is to introduce an at-rule that adds the host
element to the set of elements matched by the rules within it, perhaps
called @host. This was extraordinarily clumsy the first time we tried
to do it, but that was due to a host of other syntax issues that have
since been resolved. Now, just using @host to change the context, and
:host/:host() to select things, should work okay.
If we do this, should :host() still work in non-@host contexts? It
would match *any* element in the tree, if something in the ancestor
list, starting with the host element, matched the selector. Perhaps
it requires a different name now, to distinguish it from :host?
Part 2: Party ::part part
Another possible wrinkle is the ::part pseudo element. After also
chewing on ::part for a little while, our brave guinea pi.. erm,
people also declared it to be tasting somewhat bitter.
The best symptom can be seen here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23162. When explained
that you would just chain x-nurk::part(woot)::part(zorp)::part(bler)
to cross each shadow tree boundary, the guinea people looked at me
like this: _. Then they pointed out that this both:
a) implies ever-growing part API for each component, which will
quickly lead to the anti-pattern of developers simply declaring all
elements in their shadow tree as parts, and
b) just looks ugly and constipated.
Agitated shouts of Y U NO LET US JUS DO EET were echoing across the
San Francisco Bay, frightening America's Cup spectators.
To calm the brave guinea people down, I showed them a magic trick. Out
of my sleeve, I pulled out two new combinators: A hat (^) and a cat
(^^).
You would use them instead of ::part. The hat is generally equivalent
to a descendant combinator, except it crosses 1 (one) shadow tree
boundary (from shadow host to shadow root). The cat is similar, except
it crosses any number of boundaries. So, to target bler in the
previous part-y chain could be written as simply as
x-nurk^^[part=bler] or x-nurk^^#bler if ids are used instead of
part=bler attribute. Respectively, you would target woot as simply
x-nurk^#woot.
We talked about auto-surfacing the parts from contained components
previously. We decided not to do it, but we can address this at the
demand side by just introducing a second pseudo-element alongside
::part which selects amongst all the parts, including those of
contained components. No need to introduce new combinator syntax -
pseudo-elements are already combinators of a sort.
But wait there's more: you could use these new combinators in
querySelector, I proclaimed! In the nascent shadow DOM code, we
already started seeing the blood-curling
document.querySelector('x-nurk').shadowRoot.querySelector('#woot').shadowRoot.querySelector('#zorp')
chains of hell -- a problem that these new combinators would solve.
Think of them
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles sjmi...@google.com wrote: I'd greatly prefer to stick with the current plan of having to mark things to be exposed explicitly, Fwiw, we tried that and got in the weeds right away. See Dimitri's post for details. I'm afraid of trading real-life pain (e.g. exploding part lists) for what is IMO an unreal advantage (e.g. the notion components can be upgraded and assured never to break is just not realistic). Did you miss my suggestion that we allow this with a third value on the current allow selectors through switch? ~TJ
Re: [webcomponents]: The Shadow Cat in the Hat Edition
On Sep 9, 2013 9:32 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Sep 9, 2013 at 6:20 PM, Scott Miles sjmi...@google.com wrote: I'd greatly prefer to stick with the current plan of having to mark things to be exposed explicitly, Fwiw, we tried that and got in the weeds right away. See Dimitri's post for details. I'm afraid of trading real-life pain (e.g. exploding part lists) for what is IMO an unreal advantage (e.g. the notion components can be upgraded and assured never to break is just not realistic). Did you miss my suggestion that we allow this with a third value on the current allow selectors through switch? ~TJ I am worried that i am not understanding one or both of you properly and honestly ... I am feeling just a bit lost. For purposes here consider i have some kind of a special table component complete with sortable and configurable columns. When i use that, i honestly don't want to know what is in the sausage - just how to style or potentially deal with some parts. If i start writing things depending on the gory details, shame on me. If you leave me no choice but to do that, shame on you. You can fool me once but you can't get fooled again... Or something. Ok, so, is there a problem with things at that simple level or do the problems only arise as i build a playlist component out of that table and some other stuff and in turn a music player out of that? Is that the exploding parts list? Why is exposing explicitly bad?
