RE: Comments on version web-apps specs from 2013-10-31

[Feras Moussa]

Hi Francois,Thanks for the feedback.

> From: francois-xavier.kowal...@hp.com
> To: public-webapps@w3.org
> Date: Wed, 20 Nov 2013 20:30:47 +
> Subject: Comments on version web-apps specs from 2013-10-31
> 
> Hello
> 
> I have a few comments on: 
> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm from 2013-10-31. 
> Apologies wether it is not the latest version: It took me some time to 
> figure-out where was the right forum to send these comments to.
> 
> Section 2.1.3:
> 1. Close(): For writeable streams, the close() method does not provide a 
> data-completion hook (all-data-flushed-to-destination), unlike the close 
> method that resolved the Promise returned by read().The version of the spec 
> you linked doesn't differentiate writeable/readable streams, but is something 
> we are considering adding in a future version. I don't quite understand what 
> you're referring to here. close is independent of future reads - you can call 
> a read after close, and once EOF is reached, the promise is resolved and you 
> get a result with eof=true.
> 2. Pipe(): the readable Steam (the one that provides the pipe() method) 
> is neutered in case of I/O error, but the state change of the writeable 
> stream is not indicated. What if the write operation failed?Are you asking 
> what the chain of error propagation is when multiple streams are chained?
> 
> Section 3.2:
> 1. Shouldn't a FileWrite also be capable of consuming a Stream? (Like 
> XHR-pipe-to-FileWriter)Yes, I think so - this is a use case we can add.
> 2. Shouldn't an XMLHttpRequest also be capable of consuming a Stream? 
> (eg. chunked PUT/POST)?Section 5.4 covers this - support for posting a 
> Stream. That said, this is a section I think will need to be flushed out more.
> 
> br.
> 
> —FiX
> 
> PS: My request to join this group is pending, so please Cc me in any 
> reply/comment you may have until membership is fixed.
> 
> 
  

Re: [HTML Imports]: what scope to run in

[John J Barton]

On Wed, Nov 20, 2013 at 7:34 PM, Ryosuke Niwa  wrote:

> On Nov 21, 2013, at 10:41 AM, Hajime Morrita  wrote:
> > Seems like almost everyone agrees that we need better way to
> > modularize JavaScript, and ES6 modules are one of the most promising
> > way to go. And we also agree (I think) that we need a way to connect
> > ES6 modules and the browser.
> >
> > What we don't consent to is what is the best way to do it. One option
> > is to introduce new primitive like jorendorff's  element.
> > People are also seeing that HTML imports could be another option. So
> > the conversation could be about which is better, or whether we need
> > both or not.
>
> This is a nice summary.
>
> > * Given above, HTML imports introduces an indirection with 

Re: [HTML Imports]: what scope to run in

[Ryosuke Niwa]

On Nov 21, 2013, at 10:41 AM, Hajime Morrita  wrote:
> Seems like almost everyone agrees that we need better way to
> modularize JavaScript, and ES6 modules are one of the most promising
> way to go. And we also agree (I think) that we need a way to connect
> ES6 modules and the browser.
> 
> What we don't consent to is what is the best way to do it. One option
> is to introduce new primitive like jorendorff's  element.
> People are also seeing that HTML imports could be another option. So
> the conversation could be about which is better, or whether we need
> both or not.

This is a nice summary.

> * Given above, HTML imports introduces an indirection with 

Re: [HTML Imports]: what scope to run in

[Hajime Morrita]

I'd frame the problem in a slightly different way.

Seems like almost everyone agrees that we need better way to
modularize JavaScript, and ES6 modules are one of the most promising
way to go. And we also agree (I think) that we need a way to connect
ES6 modules and the browser.

What we don't consent to is what is the best way to do it. One option
is to introduce new primitive like jorendorff's  element.
People are also seeing that HTML imports could be another option. So
the conversation could be about which is better, or whether we need
both or not.

If you just want to namespace the script, HTML Imports might be overkill because

 * An import is HTML and HTML isn't JS developer friendly in some
cases. Think about editor integration for example. Application
developers will prefer .js rather than .html as the container of their
code.
 * Given above, HTML imports introduces an indirection with 
>> >>
>> >> Once imported, in script:
>> >> new $('mylib').import.MyCommentElement;
>> >> $('mylib').import.doStuff(12);
>> >>
>> >> or
>> >>
>> >> In markup:
>> >> 
>> >>
>> >> Once imported, in script:
>> >> new MyCommentElement;
>> >> doStuff(12);
>> >>
>> >>
>> >> How about this?
>> >>
>> >> In the host document:
>> >> 
>> >>