On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com wrote:
I haven't been following the fetch API in detail. Is there some
collective understanding of what abstraction layer fetch represents?
It's at the same level as XMLHttpRequest.
For example, I could imagine that we might not
Hi,
I occasionally have had to deal live XML feeds over HTTP
The server continuously sent HTTP chunks during the lifetime of the HTTP
connection, meaning, until the client close the connection.
I used a SAX JS lib and, on readystate === 3, had to continuously check body
changes via a
On Mon, Jun 23, 2014 at 1:36 PM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
I wonder now if such fetch API could be a better place to manage such use case
The plan is for response.body (the promise fetch() returns resolves
once all the headers are in) to be a stream:
Thanks for the redirection Anne
On 23 juin 2014, at 13:42, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jun 23, 2014 at 1:36 PM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
I wonder now if such fetch API could be a better place to manage such use
case
The plan is for
Sounds good Anne.
Its pretty easy to feature detect these capabilities now that they are
normal methods.
Patiently awaiting Streams itself to be finalized.
Thanks!
On Mon, Jun 23, 2014 at 5:15 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth
On Mon, Jun 23, 2014 at 3:15 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jun 22, 2014 at 6:10 AM, Adam Barth w...@adambarth.com wrote:
I haven't been following the fetch API in detail. Is there some
collective understanding of what abstraction layer fetch represents?
It's at the
On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@adambarth.com wrote:
XMLHttpRequest isn't particularly cleanly layered. It's sounds like
you're not overly concerned about layering, which is probably fine.
I think I see what you mean. If you wanted to implement this in terms
of JavaScript then
From: annevankeste...@gmail.com annevankeste...@gmail.com on behalf of Anne
van Kesteren ann...@annevk.nl
However, I could see it instead has to go the other way around. Instead of
having a bunch of methods on stream to convert it into various other pieces.
Other pieces could have ways of
On Mon, Jun 23, 2014 at 8:28 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, Jun 23, 2014 at 5:11 PM, Adam Barth w...@adambarth.com wrote:
XMLHttpRequest isn't particularly cleanly layered. It's sounds like
you're not overly concerned about layering, which is probably fine.
I think I
From: Adam Barth w...@adambarth.com
It might be instructive to think about how the Node community would structure
these APIs. Node has a much stronger notion of modules and dependencies than
browsers because Node uses npm. As Node developer, I would be sad if my
networking module dragged
Thats a good point.
You need a document context to do any sort of Element construction.
Fetch shouldn't have any dependency on a document since its targeting
ServiceWorkers.
I'd say asHTML isn't going to work out. But
document.parseHTMLStream(response.body) seems fine to me. A discussion
for
On Mon, Jun 23, 2014 at 8:46 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
It might be instructive to think about how the Node community would
structure these APIs. Node has a much stronger notion of modules and
dependencies than browsers because Node uses npm. As Node developer,
On Thu, Jun 19, 2014 at 4:20 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell k...@google.com wrote:
It is a little unfortunate that a canvas-specific solution is needed.
Is it known whether document.getBoxQuads solves this problem in
Firefox?
On Mon, Jun 23, 2014 at 4:25 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell k...@google.com wrote:
It's hard to predict. A more general API would be better than a
canvas-specific one, assuming it solves the problem. getBoxQuads can
return
On Tue, Jun 24, 2014 at 11:44 AM, Kenneth Russell k...@google.com wrote:
If there's no concern about potential duplicated functionality then
let's add the attributes to the canvas element. They'll be easier for
developers to understand and easier to verify as obviously correct.
How should we
On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I'll do that now.
Done.
http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o
On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Yes, increasing the set of name-alikes between html and svg is absolutely
not something we'll support. (I've unfortunately been out of the loop with
the svgwg for a while, or else I would have prevented this from
On Jun 24, 2014, at 5:25 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Yes, increasing the set of name-alikes between html and svg is absolutely
not something we'll support. (I've unfortunately been out of the
On Mon, Jun 23, 2014 at 9:35 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jun 24, 2014, at 5:25 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Yes, increasing the set of name-alikes between html and svg is
19 matches
Mail list logo
