Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Fri, Aug 22, 2014 at 12:27 AM, James Graham ja...@hoppipolla.co.uk wrote: I think that adding an extra verb to the names to describe a consistent feature of the API is a mistake; it seems important when designing the API because it's a choice that you have to make, but for the user it's just part of how the API works and not something that needs to be reemphasized in the name of every piece of API surface. For example given a language with immutable strings it would be pure noise to call a method appendAsNewString compared to just append because all mutation methods would consistently create new strings. So you argue for asX()? Perhaps bodyAsX() to make it clear what field of request/response we're talking about. And then hasBody as property or some such? That works for me too. I agree that developers will likely learn what is going on here quickly enough. And that if anything should have long names, it would be some new API that would use more memory. Jake? -- http://annevankesteren.nl/
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On 22 August 2014 07:20, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Aug 22, 2014 at 12:27 AM, James Graham ja...@hoppipolla.co.uk
wrote:
I think that adding an extra verb to the names to describe a consistent
feature of the API is a mistake; it seems important when designing the
API because it's a choice that you have to make, but for the user it's
just part of how the API works and not something that needs to be
reemphasized in the name of every piece of API surface. For example
given a language with immutable strings it would be pure noise to call a
method appendAsNewString compared to just append because all
mutation methods would consistently create new strings.
So you argue for asX()? Perhaps bodyAsX() to make it clear what field
of request/response we're talking about. And then hasBody as property
or some such?
That works for me too. I agree that developers will likely learn what
is going on here quickly enough. And that if anything should have long
names, it would be some new API that would use more memory. Jake?
Reading a url as some format is really common, so I'm in favour of shorter
method names.
var data = await (await fetch('/whatever')).asJSON();
The consuming behaviour may catch some developers out, once, in their
development environment.
I don't think Alex Domenic were as keen wanted something in the name to
represent consuming/taking.
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 22 August 2014 07:20, Anne van Kesteren ann...@annevk.nl wrote:
That works for me too. I agree that developers will likely learn what
is going on here quickly enough. And that if anything should have long
names, it would be some new API that would use more memory. Jake?
Reading a url as some format is really common, so I'm in favour of shorter
method names.
var data = await (await fetch('/whatever')).asJSON();
The consuming behaviour may catch some developers out, once, in their
development environment.
I don't think Alex Domenic were as keen wanted something in the name to
represent consuming/taking.
James pointed out on IRC we could simply have this:
response.json()
response.text()
request.formData()
I did not like this at first. However, if we care about brevity, and
we often said we do and act in that manner (see e.g. querySelector -
query), he is right. as does not really add anything. bodyAsJSON
is a bit more descriptive and takeBodyAsJSON is even more, but in
the end everyone will know very quickly that response/request can only
have their body read once and will dislike us for having to type those
extra characters (and will then type another couple to complain about
it on Twitter).
I checked and none of the existing properties clash with data types we
might want to add in the future. I think those, combined with exposing
state through hasBody should be the way forward.
--
http://annevankesteren.nl/
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Fri, Aug 22, 2014 at 5:26 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald jaffathec...@gmail.com
wrote:
On 22 August 2014 07:20, Anne van Kesteren ann...@annevk.nl wrote:
That works for me too. I agree that developers will likely learn what
is going on here quickly enough. And that if anything should have long
names, it would be some new API that would use more memory. Jake?
Reading a url as some format is really common, so I'm in favour of shorter
method names.
var data = await (await fetch('/whatever')).asJSON();
The consuming behaviour may catch some developers out, once, in their
development environment.
I don't think Alex Domenic were as keen wanted something in the name to
represent consuming/taking.
James pointed out on IRC we could simply have this:
response.json()
response.text()
request.formData()
I did not like this at first. However, if we care about brevity, and
we often said we do and act in that manner (see e.g. querySelector -
query), he is right. as does not really add anything. bodyAsJSON
is a bit more descriptive and takeBodyAsJSON is even more, but in
the end everyone will know very quickly that response/request can only
have their body read once and will dislike us for having to type those
extra characters (and will then type another couple to complain about
it on Twitter).
I checked and none of the existing properties clash with data types we
might want to add in the future. I think those, combined with exposing
state through hasBody should be the way forward.
--
http://annevankesteren.nl/
I still think that calling it bodyStream actually helps understanding
all you need and it's short/portable...
response.bodyStream.asJSON()
seems to at least give the hint that it is a stream that is consumed
without getting too crazy.
--
Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell bkard...@gmail.com wrote: I still think that calling it bodyStream actually helps understanding all you need and it's short/portable... response.bodyStream.asJSON() seems to at least give the hint that it is a stream that is consumed without getting too crazy. Well 1), response.json() is short too, much shorter in fact. 2) We have no idea what the design of what bodyStream's getter returns is or should be. 3) As already indicated, after you use this once, you realize how it works. 4) I don't see how yours is more portable than James' proposal. -- http://annevankesteren.nl/
Re: [whatwg] [Fetch] API changes to make stream depletion clearer/easier
On Fri, Aug 22, 2014 at 1:52 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell bkard...@gmail.com wrote: I still think that calling it bodyStream actually helps understanding all you need and it's short/portable... response.bodyStream.asJSON() seems to at least give the hint that it is a stream that is consumed without getting too crazy. Well 1), response.json() is short too, much shorter in fact. It is, but there was concern that is was too short to be clear/might actually be confusing before it was further shortened. Making it shorter doesn't help that objection - it doesn't make it clearer, does it? I'm not saying this is best I'm offering a proposal that tries to strike the balance with this fact - that's all there is to my comment. 2) We have no idea what the design of what bodyStream's getter returns is or should be. There was a body property, I merely proposed renaming it to bodyStream. If you're saying that we've definitely decided to not directly expose the stream, merely means of consuming because of the open question of what streams look like, then yes, that's a good argument against what I'm saying... I might have missed that that decision was made, was it? 3) As already indicated, after you use this once, you realize how it works. Yes and no... It's moderately easier to learn if the API is clearer about what is is, and it's definitely easier to recognize in code without searching for context when 'response' could be several things. It's all a balancing act of cost and benefit (see next comment) 4) I don't see how yours is more portable than James' proposal. I didn't say it was, I just said it -was- portable... You could imagine carrying the lesson that stream based properties identify themselves as such across the platform - it's not overly long and they would be easily recognizable - maybe that's a good balance, maybe it's not You could definitely make the same argument with .json(), though it's different in the sense that there is no hint as to what you can .json() and what you can't. I'm definitely not saying bodyStream or it's wrong, but the API when I suggested it as an option at least was discussing methods like response.body.consumeAsJSON which is longer, less clear to me and offers no kind of hints or portability of the idea that I can really see. -- http://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
[whatwg] Object.observe()able properties on the web platform
[Spawning new thread on public-script-coord; whatwg to bcc] From: whatwg whatwg-boun...@lists.whatwg.org on behalf of Jonas Sicking jo...@sicking.cc On Wed, Aug 20, 2014 at 1:33 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Aug 20, 2014 at 10:29 AM, Jonas Sicking jo...@sicking.cc wrote: FWIW, the web platform sorely needs a construct for readonly state variable + event whenever the state changes. I.e. some form of observable which remembers the last produced value. I had hoped the Streams would get us closer to that, but the current definition seems to be too different. Isn't that Object.observe() with custom records produced by the specific object you are defining for the property you want to enable this for (in this case held, it seems like)? That's a good question. It'd be awesome if Object.observe() solved this problem for us. One thing that I'd worry about is that it'll be hard for authors to know which properties are observable, and which ones aren't. But maybe that's something we can live with. Object.observe() is in my mind exactly what solves this problem. Remember that it doesn't work out-of-the-box for getters. And, most DOM properties are clearly getter-like from an author perspective: i.e., besides that being their actual observable implementation, they also are usually getting some underlying part of the system that is not otherwise accessible; it is hard to imagine them as simple data properties which anyone can toggle. So IMO authors will bring the same expectations to DOM objects they do to regular objects: getters will be sometimes observable, but only if the implementation of that object has taken the time to make them so. I think it would be a good idea to start working on additions to WebIDL to mark properties as observable, so that Chrome at least can start firing change records for them. I imagine this propagating to developer docs (MDN etc.) as some kind of observable annotation that authors will come, in time, to learn means they can Object.observe() that property.
[whatwg] Preloading and deferred loading of scripts and other resources
When I last looked at preloading scripts, it was pointed out to me that the Web Perf WG had some work ongoing in this space, so I decided to let them take care of it. However, nothing much seems to be happening there, and so I'm looking at this again. It's also been pointed out that limiting this to just scripts preloading maybe taking too narrow a view, and that we should also consider preloading and deferring loading of other resources, such as images, style sheets, and so forth. I will start by looking at use cases again, then go through some of the feedback on the last proposal I'd made in this space, and then make a new proposal intended to address the use cases and feedback. On Fri, 15 Aug 2014, Ben Maurer wrote: [Use-case F:] A website has a page where media is the primary content. It would like to make sure that media is downloaded before JS [e.g. flickr, youtube, facebook photos] [Use-case G:] A website knows there's a piece of Javascript code that the user might need if they click on a part of the page. The developer would like to have the user download it, but not at the expense of other resources. [Use-case H:] A website is prefetching photos in a photo album and would like to make sure these images are lower priority than images the user is actually viewing. On Mon, 28 Jul 2014, Ben Maurer wrote: [Use-case I:] Facebook uses an automated pipeline to decide what CSS/JS files to package together. If we could pass a custom header in the request for a CSS file (for example: what part of the page caused that file to be loaded) we could use this information in our packaging system to make smarter decisions. On Tue, 22 Jul 2014, Ben Maurer wrote: [Use-case J:] The way we render pages at Facebook [is essentially that we] flush sections of HTML with a list of CSS and JS dependencies for each section. The HTML is only rendered once these resources are loaded. [Use-case K:] We have a few other use cases for this type of dependency (for example, we have a method where you can say call this callback once resources X, Y and Z are requested). On Tue, 3 Sep 2013, Ryosuke Niwa wrote: [Use-case L:] A web page wants to load and execute a script widget.js if the script is already cached in the browser. However, it wants to load other essential assets such as images first if it's not already in the cache except as long as the user had not started interacting with the parts of the page that require widget.js. On Tue, 18 Mar 2014, Jonas Sicking wrote: [Use-case M:] Being able to specify that an image/video should only be downloaded on demand (aka lazily), i.e. when it's in view, or about to be in view. Use case is both to lower bandwidth in cases of long pages where the user doesn't always scroll to the bottom, as well as make sure to fill the network pipe with the most important resources first. [Use-case N:] Being able to specify that a stylesheet should not block rendering. Use case is to preload stylesheets that will be used by content that isn't rendered in the initial view, but that might be rendered later. [Use-case O:] Being able to specify some form of prioritization for resources like (non-blocking) stylesheets, (non-blocking) scripts, images, video, iframes etc. Use case is making sure to fill the network pipe with the most important resources first. Possibly a simple prioritization like needed for initial rendering/not needed for initial rendering is enough, possibly there are needs for more finegrained prioritization like needed for initial rendering/needed for page feature X that is commonly used, needed for other. On Fri, 30 Aug 2013, Yoav Weiss wrote: [Use-case P:] download dynamic page components (e.g. maps) only on larger devices. On Wed, 10 Jul 2013, Kyle Simpson wrote: [Use-case Q:] I am dynamically loading one of those social widgets that, upon load, automatically scans a page and renders social buttons. I need to be able to preload that script so it's ready to execute, but decide when I want it to run against the page. I don't want to wait for true on-demand loading, like when my user clicks a button, because of the loading delay that will be visible to the user, so I want to pre-load that script and have it waiting, ready at a moment's notice to say it's ok to execute, do it now! now! now!. [Use-case S:] One CMS plugin wants to load A.js and B.js, where B relies on A. Both need to load in parallel (for performance), but A must execute before B executes. I don't control A and B, so changing them is not an option. This CMS plugin [wants] to wait for some user-interaction, such as a button click, before executing the code. We don't want there to be any big network-loading delay visible to the user between their click of the button and the running of that plugin's code. Another CMS plugin on this same page wants to load A.js, C.js, and D.js. This
[whatwg] Web Bluetooth API
We have a draft API for Bluetooth device access at https://webbluetoothcg.github.io/web-bluetooth/, for which I'm planning to send a Blink Intent to Implement email soon. The spec isn't really up to web standard quality yet: we're planning to refine it as we get feedback from implementation and experimental use. However, we'd still appreciate any feedback this group has on the current draft. Feedback as issues at https://github.com/WebBluetoothCG/web-bluetooth/issues will be easiest to incorporate. Feedback as replies to this email is still welcome. Participation at http://lists.w3.org/Archives/Public/public-web-bluetooth/ is even more welcome. :) Thanks, Jeffrey Yasskin P.S. I'll ping Monday so this doesn't get lost over the weekend, but want to give anyone a chance to comment early if you want.
Re: [whatwg] Web Bluetooth API
It's fairly similar to the BluetoothGatt API that was posted to https://wiki.mozilla.org/B2G/Bluetooth/WebBluetooth-v2 yesterday. The FFOS API provides more control over discovery and pairing, as is appropriate for an API aimed at certified applications. We have been actively communicating with the Mozilla team, especially Shawn Huang and Marcos Caceres. On Fri, Aug 22, 2014 at 6:38 PM, Andreas Gal andr...@mozilla.com wrote: Is this similar to the API we are implementing in FFOS/Gecko? Thanks, Andreas On Aug 22, 2014, at 7:33 PM, Jeffrey Yasskin jyass...@chromium.org wrote: We have a draft API for Bluetooth device access at https://webbluetoothcg.github.io/web-bluetooth/, for which I'm planning to send a Blink Intent to Implement email soon. The spec isn't really up to web standard quality yet: we're planning to refine it as we get feedback from implementation and experimental use. However, we'd still appreciate any feedback this group has on the current draft. Feedback as issues at https://github.com/WebBluetoothCG/web-bluetooth/issues will be easiest to incorporate. Feedback as replies to this email is still welcome. Participation at http://lists.w3.org/Archives/Public/public-web-bluetooth/ is even more welcome. :) Thanks, Jeffrey Yasskin P.S. I'll ping Monday so this doesn't get lost over the weekend, but want to give anyone a chance to comment early if you want.
