Re: [XHR]

[Jonas Sicking]

On Wed, Mar 16, 2016 at 1:54 PM, Gomer Thomas
 wrote:
> but I need a cross-browser solution in the near future

Another solution that I think would work cross-browser is to use
"text/plain;charset=ISO-8859-15" as content-type.

That way I *think* you can simply read xhr.responseText to get an ever
growing string with the data downloaded so far. Each character in the
string represents one byte of the downloaded data. So to get the 15th
byte, use xhr.responseText.charAt(15).

/ Jonas

Re: Telecon / meeting on first week of April for Web Components

[Takayoshi Kochi]

I will join remotely via webex.

On Tue, Mar 15, 2016 at 7:08 PM, Léonie Watson  wrote:

> For a telecon, we can create a WebEx instance if that would be useful? Let
> me know the date/time (UTC), and we'll get it sorted.
>
> For an F2F, we'll need to post notice of the date/venue at least eight
> weeks
> in advance [1]. Let me know the date(s)/venue, and we can do that too.
>
> Léonie.
> [1]
> https://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0043.html
>
>
> > -Original Message-
> > From: rn...@apple.com [mailto:rn...@apple.com]
> > Sent: 14 March 2016 23:56
> > To: t...@tink.uk; Chaals McCathie Nevile 
> > Cc: public-webapps 
> > Subject: Telecon / meeting on first week of April for Web Components
> >
> > Hi all,
> >
> > We've been making a good progress on shadow DOM and custom elements
> > API but there seems to be a lot of open questions still.  I've asked a
> couple of
> > people involved in the discussion, and there seems to be an interest for
> > having another tele-conference or an in-person meeting.
> >
> > Can we schedule one in the second week of April (April 4th through 8th)?
> >
> > - R. Niwa
>
>
>
>


-- 
Takayoshi Kochi

RE: [XHR]

[Gomer Thomas]

  Hi Karl,
  Thanks for weighing in. 
  The issue I was intending to raise was not really parsing XML or 
JSON or anything like that. It was using chunked delivery of an HTTP response 
as it is intended to be used -- to allow a client to consume the chunks as they 
arrive, rather than waiting for the entire response to arrive before using any 
of it. The requirement to support chunked delivery is specified in section 
3.3.1 of RFC 7230. The details of the chunk headers, etc., are contained in 
section 4.1. 
  Regards, Gomer
  --
  Gomer Thomas Consulting, LLC
  9810 132nd St NE
  Arlington, WA 98223
  Cell: 425-309-9933
  
  
  -Original Message-
   From: Karl Dubost [mailto:k...@la-grange.net] 
   Sent: Wednesday, March 16, 2016 7:20 PM
   To: Hallvord R. M. Steen 
   Cc: Gomer Thomas ; WebApps WG 

   Subject: Re: [XHR]
  
  Hallvord et al.
  
  Le 16 mars 2016 à 20:04, Hallvord Reiar Michaelsen Steen 
 a écrit :
  > How would you parse for example an incomplete JSON source to 
expose an 
  > object? Or incomplete XML markup to create a document? Exposing 
  > partial responses for text makes sense - for other types of 
data 
  > perhaps not so much.
  
  I don't think you are talking about the same "parse".
  
  The RFC 7230 corresponding section is:
  http://tools.ietf.org/html/rfc7230#section-4.1
  
  This is the HTTP specification. The content of the specification 
is about parsing **HTTP** information, not about parsing the content of a body. 
A JSON, XML, HTML parser is not the domain of HTTP. It's a separate piece of 
code. 
  
  Note also for JSON or XML, an incomplete transfert or chunked as 
text or binary means you can still receive the stream of bytes and choose to 
serialize it as text or binary, which a JSON or XML processing tool decide to 
do whatever they want with it. The same way a validating parser would start 
parsing **something** (as long as it's not completed) and bails out when it 
finds it invalid. 
  
  
  --
  Karl Dubost 
  http://www.la-grange.net/karl/
  

Re: HTML5's Offline-first Council of Trent

[Nick Dugger]

> Nick, while we're waiting for Léonie to lecture you
on participation-criteria,  etiquette, and social competence [...]

That was actually my very first message on any of these mailing lists, so
it was manually approved by a moderator. I'm very confused about how you
think I broke etiquette and you did not? This whole thread could be the
poster child of how not to engage with other people.

Thanks,
Nick Dugger

On Fri, Mar 18, 2016, 4:48 AM Patrick H. Lauke 
wrote:

> On 18/03/2016 03:52, Richard Maher wrote:
> > I've found someone who has more credibility and form here and is willing
> > to take the idea forward.
>
> Let's hope that someone also understands what it means to make a
> technical argument, without resorting to some House of Commons Tory
> Obxbridge debating style with thinly veiled ad-hominems.
>
> https://twitter.com/JoeSondow/status/692170578023862273
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>

Re: [XHR]

[Sangwhan Moon]

> On Mar 17, 2016, at 3:12 AM, Jonas Sicking  wrote:
> 
>> On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr.  
>> wrote:
>> No, streams do not solve the problem of "how do you present a
>> partially-downloaded JSON object".  They handle chunked data *better*,
>> so they'll improve "text" response handling,
> 
> Also binary handling should be improved with streams.
> 
>> but there's still the
>> fundamental problem that an incomplete JSON or XML document can't, in
>> general, be reasonably parsed into a result.  Neither format is
>> designed for streaming.
> 
> Indeed.
> 
>> (This is annoying - it would be nice to have a streaming-friendly JSON
>> format.  There are some XML variants that are streaming-friendly, but
>> not "normal" XML.)
> 
> For XML there is SAX. However I don't think XML sees enough usage
> these days that it'd be worth adding native support for SAX to the
> platform. Better rely on libraries to handle that use case.
> 
> While JSON does see a lot of usage these days, I've not heard of much
> usage of streaming JSON. But maybe others have?
> 
> Something like SAX but for JSON would indeed be cool, but I'd rather
> see it done as libraries to demonstrate demand before we add it to the
> platform.

Something like SAX for JSON would be nice.

For an immediately available userland solution RFC7049 is an alternative to 
JSON which is slightly more streaming friendly.

Downside is that it's unreadable by humans, and a bit too low level for a fair 
amount of usecases. (Parsing is much simpler than existing binary object 
serialization formats, such as ASN1)

Sangwhan

[1] https://tools.ietf.org/html/rfc7049

Re: HTML5's Offline-first Council of Trent

[Anders Rundgren]

On 2016-03-17 07:12, Richard Maher wrote:

An even more powerful (but also ignored possibility) would be COMBINING the 
power
of the Web and App worlds instead of fighting religious wars ("the Web is 
great"),
where there are no winners, only lost opportunities.


That's what plugins were for wan't it? And I still cry every night over the 
death of Applets :-(
(A single mutliplexed (static) TCP/IP full-duplex connection per user-agent!)


Plugins were deprecated which (IMO) was OK since they had serious security 
issues, what's
less satisfactory is removing features without consider some kind of reasonable 
replacement.

Several other somewhat related features are currently also subject to 
removal/deprecation.



It gets worse...if you are the Web tech leader then you are apparently free 
taking
this "shortcut" (some people would rather characterize this as an intelligent 
use
of available resources and competences), and get away with it as well:
https://github.com/w3c/webpayments/issues/42#issuecomment-166705416


C'mon Anders, do you blame them?


Well, Google more or less wrote the "Grand Plan" and now they are defecting 
from it,
while leaving everybody else with the old (non-working) plan and 
_severely_disadvantaged_.



Faced with the intractability, self-interest, and narcissism  surrounding

> the IOC^h^h^hW3C Gordian knot, are you really surprised that  someone owning
> the implementation will pull out their sword and opt for results over process?

I (naively) thought that maybe _somebody_else_ (with more influence than a
non-member like me), would be interested in taking a closer look at this
powerful capability.  I only seek a constructive discussion on what to do now.

Anders




On Thu, Mar 17, 2016 at 1:34 PM, Anders Rundgren > wrote:

On 2016-03-17 06:00, Richard Maher wrote:

Hi Patrick (Congratulations on today) Technical Point follows: -

On a merit-based resource allocation basis, the two most fundamental, 
essential,

> and absolutely necessary HTML5 Web-App feature enhancements are: -


1) Background GPS device/user tracking support
2) Push API 1:M broadcast capability

These are enabling technologies that will catapult HTML5 Web Apps into 
the

> Native App heartland and single-handedly alter the development-tool and 
deployment
> strategies for Mobile App vendors around the world.

An even more powerful (but also ignored possibility) would be COMBINING the 
power
of the Web and App worlds instead of fighting religious wars ("the Web is 
great"),
where there are no winners, only lost opportunities.

It gets worse...if you are the Web tech leader then you are apparently free 
taking
this "shortcut" (some people would rather characterize this as an 
intelligent use
of available resources and competences), and get away with it as well:
https://github.com/w3c/webpayments/issues/42#issuecomment-166705416

Anders


The reason these features do not appear on the W3C horizon is that they 
show-case online-first and are anathema to the Offline-First Mafia that is 
currently setting the agenda and feathering its own nest.

Technically, I have to admit to having absolutely no idea how a W3C 
performance review would be conducted or how ROI on a given contributor's input 
could be measured. I am a simple man who just needs a couple more tools in the 
box in order to deliver the killer Web Apps my users are begging for.

Where I come from, and certainly from my experience in London finance, 
it's all about getting the job done! You can have two heads and be the most 
obnoxious Maher in the world but you're paid to do a job and get around the Sir 
Humphrey Appleby speed humps on the road the progress in order to do it.

I'm not here to make friends or see how many followers I can get on 
Twitter, and I apologize for being the only one without an original selfie of 
myself looking wistfully off camera, but I'm motivated by results and not 
married to the process.

HTML5 - Web Apps "The journey is *NOT* the destination!

On Wed, Mar 16, 2016 at 5:58 PM, Patrick H. Lauke  >> wrote:

 On 16/03/2016 04:46, Richard Maher wrote:
 ...

 Anyway, if the decorum police will agree to stay their 
truncheons for a
 moment longer and indulge my use of satire, parody, and 
metaphor, in
 making an extremely valid technical point,

 ...

 Or you could just make your valid technical point, without 
resorting to your sarcastic tone which, frankly, is quite grating and is doing 
you no favors in getting at least some of the readership on this  list to even 
want to engage in your argument.

RE: [XHR]

[Gomer Thomas]

   Thanks for the information. The "moz-blob" data type looks like it would 
work, but I need a cross-browser solution in the near future, for new browsers 
at least. It looks like I might need to fall back on a WebSocket solution with 
a proprietary protocol between the WebSocket server and applications. 
   
   The annoying thing is that the W3C XMLHttpRequest() specification of 
August 2009 contained exactly what I need:
   
The responseBody attribute, on getting, must return the result of 
running the following steps:
   
If the state is not LOADING or DONE raise an INVALID_STATE_ERR 
exception and terminate these steps.
   
Return a ByteArray object representing the response entity body or 
return null if the response entity body is null.
   
   Thus, for byteArray data one could access the partially delivered 
response. For some reason a restriction was added later that removed this 
capability, by changing "If the state is not LOADING or DONE" to "If the state 
is not DONE" for all data types except "text". Alas. I still don't understand 
why W3C and WHATWG added this restriction. Normally new releases of a standard 
add capabilities, rather than taking them away. It is especially puzzling in 
this situation, since it basically blows off the IETF RFC 7230 requirement that 
HTTP clients must support chunked responses. 
   
   Regards, Gomer
   
   --
   Gomer Thomas Consulting, LLC
   9810 132nd St NE
   Arlington, WA 98223
   Cell: 425-309-9933
   
   
   -Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Wednesday, March 16, 2016 1:01 PM
To: Gomer Thomas 
Cc: Hallvord Reiar Michaelsen Steen ; WebApps WG 

Subject: Re: [XHR]
   
   Sounds like you want access to partial binary data.
   
   There's some propitiatory features in Firefox which lets you do this 
(added ages ago). See [1]. However for a cross-platform solution we're still 
waiting for streams to be available.
   
   Hopefully that should be soon, but of course cross-browser support 
across all major browsers will take a while. Even longer if you want to be 
compatible with old browsers still in common use.
   
   [1] 
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseType
   
   / Jonas
   
   On Wed, Mar 16, 2016 at 12:27 PM, Gomer Thomas 
 wrote:
   >In my case the object being transmitted is an ISO BMFF file (as 
a blob), and I want to be able to present the samples in the file as they 
arrive, rather than wait until the entire file has been received.
   >Regards, Gomer
   >
   >--
   >Gomer Thomas Consulting, LLC
   >9810 132nd St NE
   >Arlington, WA 98223
   >Cell: 425-309-9933
   >
   >
   >-Original Message-
   > From: Hallvord Reiar Michaelsen Steen [mailto:hst...@mozilla.com]
   > Sent: Wednesday, March 16, 2016 4:04 AM
   > To: Gomer Thomas 
   > Cc: WebApps WG 
   > Subject: Re: [XHR]
   >
   >On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas 
 wrote:
   >
   >> According to IETF RFC 7230 all HTTP recipients “MUST be able 
to parse
   >> the chunked transfer coding”. The logical interpretation of 
this is
   >> that whenever possible HTTP recipients should deliver the 
chunks to
   >> the application as they are received, rather than waiting for 
the
   >> entire response to be received before delivering anything.
   >>
   >> In the latest version this can only be done for “text” 
responses. For
   >> any other type of response, the “response” attribute returns 
“null”
   >> until the transmission is completed.
   >
   >How would you parse for example an incomplete JSON source to 
expose an object? Or incomplete XML markup to create a document? Exposing 
partial responses for text makes sense - for other types of data perhaps not so 
much.
   >-Hallvord
   >
   >

RE: [XHR]

[Gomer Thomas]

   In my case the object being transmitted is an ISO BMFF file (as a blob), 
and I want to be able to present the samples in the file as they arrive, rather 
than wait until the entire file has been received. 
   Regards, Gomer
   
   --
   Gomer Thomas Consulting, LLC
   9810 132nd St NE
   Arlington, WA 98223
   Cell: 425-309-9933
   
   
   -Original Message-
From: Hallvord Reiar Michaelsen Steen [mailto:hst...@mozilla.com] 
Sent: Wednesday, March 16, 2016 4:04 AM
To: Gomer Thomas 
Cc: WebApps WG 
Subject: Re: [XHR]
   
   On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas 
 wrote:
   
   > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse 
   > the chunked transfer coding”. The logical interpretation of this is 
   > that whenever possible HTTP recipients should deliver the chunks to 
   > the application as they are received, rather than waiting for the 
   > entire response to be received before delivering anything.
   >
   > In the latest version this can only be done for “text” responses. For 
   > any other type of response, the “response” attribute returns “null” 
   > until the transmission is completed.
   
   How would you parse for example an incomplete JSON source to expose an 
object? Or incomplete XML markup to create a document? Exposing partial 
responses for text makes sense - for other types of data perhaps not so much.
   -Hallvord

Re: [XHR]

[Jonas Sicking]

Sounds like you want access to partial binary data.

There's some propitiatory features in Firefox which lets you do this
(added ages ago). See [1]. However for a cross-platform solution we're
still waiting for streams to be available.

Hopefully that should be soon, but of course cross-browser support
across all major browsers will take a while. Even longer if you want
to be compatible with old browsers still in common use.

[1] https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseType

/ Jonas

On Wed, Mar 16, 2016 at 12:27 PM, Gomer Thomas
 wrote:
>In my case the object being transmitted is an ISO BMFF file (as a 
> blob), and I want to be able to present the samples in the file as they 
> arrive, rather than wait until the entire file has been received.
>Regards, Gomer
>
>--
>Gomer Thomas Consulting, LLC
>9810 132nd St NE
>Arlington, WA 98223
>Cell: 425-309-9933
>
>
>-Original Message-
> From: Hallvord Reiar Michaelsen Steen [mailto:hst...@mozilla.com]
> Sent: Wednesday, March 16, 2016 4:04 AM
> To: Gomer Thomas 
> Cc: WebApps WG 
> Subject: Re: [XHR]
>
>On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas 
>  wrote:
>
>> According to IETF RFC 7230 all HTTP recipients “MUST be able to parse
>> the chunked transfer coding”. The logical interpretation of this is
>> that whenever possible HTTP recipients should deliver the chunks to
>> the application as they are received, rather than waiting for the
>> entire response to be received before delivering anything.
>>
>> In the latest version this can only be done for “text” responses. For
>> any other type of response, the “response” attribute returns “null”
>> until the transmission is completed.
>
>How would you parse for example an incomplete JSON source to expose an 
> object? Or incomplete XML markup to create a document? Exposing partial 
> responses for text makes sense - for other types of data perhaps not so much.
>-Hallvord
>
>

Re: Meeting for selection API at TPAC?

[Ryosuke Niwa]

> On Mar 16, 2016, at 12:46 PM, Chaals McCathie Nevile  
> wrote:
> 
> On Wed, 16 Mar 2016 16:42:07 +0100, Ryosuke Niwa  wrote:
> 
>> Thanks for the rely.
>> 
>> Léonie & Chaals, could we allocate a time slot to discuss selection?
> 
> Sure. Any preferences for minimising clashes? How long do you think you need?

Please avoid conflicts with any CSS / Perf / Editing meetings.  I'd imagine we 
need 1-2 hours.

- R. Niwa

RE: [XHR]

[Domenic Denicola]

From: Gomer Thomas [mailto:go...@gomert-consulting.com]


>   [GT] It would be good to say this in the specification, and 
> reference
> some sample source APIs. (This is an example of what I meant when I said it
> is very difficult to read the specification unless one already knows how it is
> supposed to work.)

Hmm, I think that is pretty clear in https://streams.spec.whatwg.org/#intro. Do 
you have any ideas on how to make it clearer?

>   [GT] I did follow the link before I sent in my questions. In 
> section 2.5 it
> says "The queuing strategy assigns a size to each chunk, and compares the
> total size of all chunks in the queue to a specified number, known as the high
> water mark. The resulting difference, high water mark minus total size, is
> used to determine the desired size to fill the stream’s queue." It appears
> that this is incorrect. It does not seem to jibe with the default value and 
> the
> examples. As far as I can tell from the default value and the examples, the
> high water mark is not the total size of all chunks in the queue. It is the
> number of chunks in the queue.

It is both, because in these cases "size" is measured to be 1 for all chunks by 
default. If you supply a different definition of size, by passing a size() 
method, as Fetch implementations do, then you will get a difference.

>[GT] My original question was directed at how an application can issue 
> an
> XMLHttpRequest() call and retrieve the results piecewise as they arrive,
> rather than waiting for the entire response to arrive. It looks like Streams
> might meet this need, but It would take quite a lot of study to figure out how
> to make this solution work, and the actual code would be pretty complex. I
> would also not be able to use this approach as a mature technology in a
> cross-browser environment for quite a while -- years? I think we will need to
> implement a non-standard solution based on WebSocket messages for now.
> We can then revisit the issue later. Thanks again for your help.

Well, you can be the judge of how complex. 
https://fetch.spec.whatwg.org/#fetch-api, 
https://googlechrome.github.io/samples/fetch-api/fetch-response-stream.html, 
and https://jakearchibald.com/2016/streams-ftw/ can give you some more help and 
examples.

I agree that it might be a while for this to arrive cross-browser. I know it's 
in active development in WebKit, and Mozilla was hoping to begin work soon, but 
indeed for today's apps you're probably better off with a custom solution based 
on web sockets, if you control the server as well as the client.

Re: HTML editors meeting

[Chaals McCathie Nevile]

Dear Ms2ger,

On Wed, 16 Mar 2016 09:56:58 +0100, Ms2ger  wrote:


Hi Léonie,

Please don't send spam about your HTML fork to this mailing list; we were
promised the WG merge would not cause our time to be wasted with that  
crap.


This message fails to meet the minimum standards required for polite  
discussion.


Please refresh your memory of the group's workmode, including expected  
standards of behaviour.


cheers

Chaals (as co-chair).


Thanks
Ms2ger

On Tue, Mar 15, 2016 at 11:39 PM, Léonie Watson  wrote:


Hello,

There will be an HTML editors meeting on 10 - 11 May 2016, at Microsoft  
in

Redmond. Info here:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/10-11mayHTML.md

If you are interested in joining the HTML editorial team, we would like  
to

hear from you. Whilst anybody can submit a PR proposing a change to the
HTML
spec, the editorial team is responsible for reviewing PRs and merging  
them

into the spec when they are ready.

Léonie.

--
@LeonieWatson tink.uk Carpe diem.










--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

RE: [XHR]

[Domenic Denicola]

From: Elliott Sprehn [mailto:espr...@chromium.org] 

> Can we get an idl definition too? You shouldn't need to read the algorithm to 
> know the return types.

Streams, like promises/maps/sets, are not specced or implemented using the IDL 
type system. (Regardless, the Web IDL's return types are only documentation.)

Re: [XHR]

[Jonathan Garbee]

If I understand correctly, streams [1] with fetch should solve this
use-case.

[1] https://streams.spec.whatwg.org/

On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen <
hst...@mozilla.com> wrote:

> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas
>  wrote:
>
> > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the
> > chunked transfer coding”. The logical interpretation of this is that
> > whenever possible HTTP recipients should deliver the chunks to the
> > application as they are received, rather than waiting for the entire
> > response to be received before delivering anything.
> >
> > In the latest version this can only be done for “text” responses. For any
> > other type of response, the “response” attribute returns “null” until the
> > transmission is completed.
>
> How would you parse for example an incomplete JSON source to expose an
> object? Or incomplete XML markup to create a document? Exposing
> partial responses for text makes sense - for other types of data
> perhaps not so much.
> -Hallvord
>
>

Re: HTML5's Offline-first Council of Trent

[Richard Maher]

Hi Patrick (Congratulations on today) Technical Point follows: -

On a merit-based resource allocation basis, the two most fundamental,
essential, and absolutely necessary HTML5 Web-App feature enhancements are:
-

1) Background GPS device/user tracking support
2) Push API 1:M broadcast capability

These are enabling technologies that will catapult HTML5 Web Apps into the
Native App heartland and single-handedly alter the development-tool and
deployment strategies for Mobile App vendors around the world.

The reason these features do not appear on the W3C horizon is that they
show-case online-first and are anathema to the Offline-First Mafia that is
currently setting the agenda and feathering its own nest.

Technically, I have to admit to having absolutely no idea how a W3C
performance review would be conducted or how ROI on a given contributor's
input could be measured. I am a simple man who just needs a couple more
tools in the box in order to deliver the killer Web Apps my users are
begging for.

Where I come from, and certainly from my experience in London finance, it's
all about getting the job done! You can have two heads and be the most
obnoxious Maher in the world but you're paid to do a job and get around the
Sir Humphrey Appleby speed humps on the road the progress in order to do
it.

I'm not here to make friends or see how many followers I can get on
Twitter, and I apologize for being the only one without an original selfie
of myself looking wistfully off camera, but I'm motivated by results and
not married to the process.

HTML5 - Web Apps "The journey is *NOT* the destination!

On Wed, Mar 16, 2016 at 5:58 PM, Patrick H. Lauke 
wrote:

> On 16/03/2016 04:46, Richard Maher wrote:
> ...
>
>> Anyway, if the decorum police will agree to stay their truncheons for a
>> moment longer and indulge my use of satire, parody, and metaphor, in
>> making an extremely valid technical point,
>>
> ...
>
> Or you could just make your valid technical point, without resorting to
> your sarcastic tone which, frankly, is quite grating and is doing you no
> favors in getting at least some of the readership on this  list to even
> want to engage in your argument.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>

Re: Meeting for selection API at TPAC?

[Chaals McCathie Nevile]

On Wed, 16 Mar 2016 16:42:07 +0100, Ryosuke Niwa  wrote:


Thanks for the rely.

Léonie & Chaals, could we allocate a time slot to discuss selection?


Sure. Any preferences for minimising clashes? How long do you think you  
need?


cheers

Chaals


On Mar 15, 2016, at 8:33 PM, Yoshifumi Inoue  wrote:

Sorry for late response.

I would like to discuss following topics:
1. Selection for Shadow DOM
2. Multiple Range support
3. Resolution of open issues towards FPWD

- yosi

2016年3月15日(火) 9:21 Ryosuke Niwa >:

Hi all,

Is there any interest in discussing selection API at TPAC?

There are 32 open issues on Github at the moment:
https://github.com/w3c/selection-api/issues  



- R. Niwa







--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

RE: [XHR]

[Domenic Denicola]

From: Gomer Thomas [mailto:go...@gomert-consulting.com] 

> I looked at the Streams specification, and it seems pretty immature and 
> underspecified. I’m not sure it is usable by someone who doesn’t already know 
> how it is supposed to work before reading the specification. How many of the 
> major web browsers are supporting it?

Thanks for the feedback. Streams is intended to be a lower-level primitive used 
by other specifications, primarily. By reading it you're supposed to learn how 
to implement your own streams from basic underlying source APIs.

> (1) The constructor of the ReadableStream object is “defined” by 
> Constructor (underlyingSource = { }, {size, highWaterMark = 1 } = { } )
> The “specification” states that the underlyingSource object “can” implement 
> various methods, but it does not say anything about how to create or identify 
> a particular underlyingSource

As you noticed, specific underlying sources are left to other places. Those 
could be other specs, like Fetch:

https://fetch.spec.whatwg.org/#concept-construct-readablestream

or it could be used by authors directly:

https://streams.spec.whatwg.org/#example-rs-push-no-backpressure

> In my case I want to receive a stream from a remote HTTP server. What do I 
> put in for the underlyingSource?

This is similar to asking the question "I want to create a promise for an 
animation. What do I put in the `new Promise(...)` constructor?" In other 
words, a ReadableStream is a data type that can stream anything, and the actual 
capability needs to be supplied by your code. Fetch supplies one underlying 
source, for HTTP responses.

> Also, what does the “highWaterMark” parameter mean? The “specification” says 
> it is part of the queuing strategy object, but it does not say what it does.

Hmm, I think the links (if you follow them) are fairly clear. 
https://streams.spec.whatwg.org/#queuing-strategy. Do you have any suggestions 
on how to make it clearer?

> Is it the maximum number of bytes of unread data in the Stream? If so, it 
> should say so.

Close; it is the maximum number of bytes before a backpressure signal is sent. 
But, that is already exactly what the above link (which was found by clicking 
the links "queuing strategy" in the constructor definition) says, so I am not 
sure what you are asking for.

> If the “size” parameter is omitted, is the underlyingSource free to send 
> chunks of any size, including variable sizes?

Upon re-reading, I agree it's not 100% clear that the size() function maps to 
"The queuing strategy assigns a size to each chunk". However, the behavior of 
how the stream uses the size() function is defined in a lot of detail if you 
follow the spec. I agree maybe it could use some more non-normative notes 
explaining, and will work to add some, but in the end if you really want to 
understand what happens you need to either read the spec's algorithms or wait 
for someone to write an in-depth tutorial somewhere like MDN.

> (2) The ReadableStream class has a “getReader()” method, but the 
> specification gives no hint as to the data type that this method returns. I 
> suspect that it is an object of the ReadableStreamReader class, but if so it 
> would be nice if the “specification” said so.

This is actually normatively defined if you click the link in the step "Return 
AcquireReadableStreamReader(this)," whose first line tells you what it 
constructs (indeed, a ReadableStreamReader).

RE: [XHR]

[Gomer Thomas]

Thanks for the suggestion.

 

I looked at the Streams specification, and it seems pretty immature and 
underspecified. I’m not sure it is usable by someone who doesn’t already know 
how it is supposed to work before reading the specification. How many of the 
major web browsers are supporting it?

 

For example:

(1)The constructor of the ReadableStream object is “defined” by 

Constructor (underlyingSource = { }, {size, highWaterMark = 1 } = { } )

The “specification” states that the underlyingSource object “can” implement 
various methods, but it does not say anything about how to create or identify a 
particular underlyingSource. In my case I want to receive a stream from a 
remote HTTP server. What do I put in for the underlyingSource? What does the 
underlyingSource on the remote server need to do? Also, what does the 
“highWaterMark” parameter mean? The “specification” says it is part of the 
queuing strategy object, but it does not say what it does. Is it the maximum 
number of bytes of unread data in the Stream? If so, it should say so. If the 
“size” parameter is omitted, is the underlyingSource free to send chunks of any 
size, including variable sizes?

(2)The ReadableStream class has a “getReader()” method, but the 
specification gives no hint as to the data type that this method returns. I 
suspect that it is an object of the ReadableStreamReader class, but if so it 
would be nice if the “specification” said so. 

 

Regards, Gomer

--

Gomer Thomas Consulting, LLC

9810 132nd St NE

Arlington, WA 98223

Cell: 425-309-9933

 

From: Jonathan Garbee [mailto:jonathan.gar...@gmail.com] 
Sent: Wednesday, March 16, 2016 5:10 AM
To: Hallvord Reiar Michaelsen Steen ; Gomer Thomas 

Cc: WebApps WG 
Subject: Re: [XHR]

 

If I understand correctly, streams [1] with fetch should solve this use-case.

 

[1] https://streams.spec.whatwg.org/

 

On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen 
 > wrote:

On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas
 > wrote:

> According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the
> chunked transfer coding”. The logical interpretation of this is that
> whenever possible HTTP recipients should deliver the chunks to the
> application as they are received, rather than waiting for the entire
> response to be received before delivering anything.
>
> In the latest version this can only be done for “text” responses. For any
> other type of response, the “response” attribute returns “null” until the
> transmission is completed.

How would you parse for example an incomplete JSON source to expose an
object? Or incomplete XML markup to create a document? Exposing
partial responses for text makes sense - for other types of data
perhaps not so much.
-Hallvord

RE: [XHR]

[Elliott Sprehn]

Can we get an idl definition too? You shouldn't need to read the algorithm
to know the return types.
On Mar 17, 2016 12:09 PM, "Domenic Denicola"  wrote:

> From: Gomer Thomas [mailto:go...@gomert-consulting.com]
>
> > I looked at the Streams specification, and it seems pretty immature and
> underspecified. I’m not sure it is usable by someone who doesn’t already
> know how it is supposed to work before reading the specification. How many
> of the major web browsers are supporting it?
>
> Thanks for the feedback. Streams is intended to be a lower-level primitive
> used by other specifications, primarily. By reading it you're supposed to
> learn how to implement your own streams from basic underlying source APIs.
>
> > (1) The constructor of the ReadableStream object is “defined” by
> > Constructor (underlyingSource = { }, {size, highWaterMark = 1 } = { } )
> > The “specification” states that the underlyingSource object “can”
> implement various methods, but it does not say anything about how to create
> or identify a particular underlyingSource
>
> As you noticed, specific underlying sources are left to other places.
> Those could be other specs, like Fetch:
>
> https://fetch.spec.whatwg.org/#concept-construct-readablestream
>
> or it could be used by authors directly:
>
> https://streams.spec.whatwg.org/#example-rs-push-no-backpressure
>
> > In my case I want to receive a stream from a remote HTTP server. What do
> I put in for the underlyingSource?
>
> This is similar to asking the question "I want to create a promise for an
> animation. What do I put in the `new Promise(...)` constructor?" In other
> words, a ReadableStream is a data type that can stream anything, and the
> actual capability needs to be supplied by your code. Fetch supplies one
> underlying source, for HTTP responses.
>
> > Also, what does the “highWaterMark” parameter mean? The “specification”
> says it is part of the queuing strategy object, but it does not say what it
> does.
>
> Hmm, I think the links (if you follow them) are fairly clear.
> https://streams.spec.whatwg.org/#queuing-strategy. Do you have any
> suggestions on how to make it clearer?
>
> > Is it the maximum number of bytes of unread data in the Stream? If so,
> it should say so.
>
> Close; it is the maximum number of bytes before a backpressure signal is
> sent. But, that is already exactly what the above link (which was found by
> clicking the links "queuing strategy" in the constructor definition) says,
> so I am not sure what you are asking for.
>
> > If the “size” parameter is omitted, is the underlyingSource free to send
> chunks of any size, including variable sizes?
>
> Upon re-reading, I agree it's not 100% clear that the size() function maps
> to "The queuing strategy assigns a size to each chunk". However, the
> behavior of how the stream uses the size() function is defined in a lot of
> detail if you follow the spec. I agree maybe it could use some more
> non-normative notes explaining, and will work to add some, but in the end
> if you really want to understand what happens you need to either read the
> spec's algorithms or wait for someone to write an in-depth tutorial
> somewhere like MDN.
>
> > (2) The ReadableStream class has a “getReader()” method, but the
> specification gives no hint as to the data type that this method returns. I
> suspect that it is an object of the ReadableStreamReader class, but if so
> it would be nice if the “specification” said so.
>
> This is actually normatively defined if you click the link in the step
> "Return AcquireReadableStreamReader(this)," whose first line tells you what
> it constructs (indeed, a ReadableStreamReader).
>
>

Re: HTML5's Offline-first Council of Trent

[Michiel Bijl]

> On 18 Mar 2016, at 04:52, Richard Maher  wrote:
> 
> Nick, while we're waiting for Léonie to lecture you on 
> participation-criteria,  etiquette, and social competence, let me call on the 
> late, great, Rodney Dangerfield to proxy my response: -

Could you please adjust your attitude towards members of this working group? We 
are here to improve the web, not to insult people. 

Thank you. 
—Michiel