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
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
>
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 the
> 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 yo
> 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 h
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
> perha
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'
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 ap
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
98
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 sup
> 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
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
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 pol
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 on
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 7
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
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 w
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
> maj
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?
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
> unders
> 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 m
21 matches
Mail list logo
