Re: HTML5's Offline-first Council of Trent

[Chaals McCathie Nevile]

The chairs and various individuals requested that Mr Maher use a tone  
acceptable in this group.


This email once again fails to meet the minimum standards of politeness  
and constructive behaviour for this group.


Mr Maher has been removed from the mailing list.

for the chairs

chaals

On Fri, 18 Mar 2016 04:52:27 +0100, 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: -

*Judge Smails*: You have worn out your welcome, sir!
*Czervik*: Is that so? Who made you Pope of this dump?
*Judge Smails*: Bushwood...a "dump"? Well, I'll guarantee you'll never  
be a

member here!
*Czervik*: Are you kidding? You think I'd join this crummy "snobatorium"?
Why, this whole place sucks!

Now that I think about it I haven't come across a black face here yet,  
very

few females, and not many Jewish names. Maybe it's still "too soon" for
Reformation references in the W3C Country Club? (BTW. On the FTF-jolly
stakes the IETF Club kicks your arse with Honolulu and Yokohama versus  
your

Sapporo and Lisbon.)


Fresh start? If you make a good case, without calling the w3c a mafia,

people might actually engage this more seriously.

Rest assured, I am pulling out of these forums. (I'm just happy to know
that a softer gentler place continues to exist somewhere)

I've found someone who has more credibility and form here and is willing  
to
take the idea forward. Background GeoLocation was a massive issue before  
I

pinned my colours too it and is too important to the HTML5 Web App future
to be tarnished by collateral bigotry and prejudice.

But before I go, why do you all look and sound the same?

On Thu, Mar 17, 2016 at 8:49 PM, Nick Dugger   
wrote:



Listen, you may not be here to make friends, but if you want to incite
change, you might try playing nicely. If you just want results, you'll  
have

greater success without your sarcasm and superiority complex.

Fresh start? If you make a good case, without calling the w3c a mafia,
people might actually engage this more seriously. As of right now, I  
can't

speak for everyone, but I definitely don't like your tone.

Thanks,
Nick Dugger

On Thu, Mar 17, 2016, 1:52 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:


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 <
anders.rundgren@gmail.com >
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 

Re: HTML5's Offline-first Council of Trent

[Richard Maher]

> 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!)

> 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?

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?


On Thu, Mar 17, 2016 at 1:34 PM, Anders Rundgren <
anders.rundgren@gmail.com> 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.
>>
>> 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?

[Ryosuke Niwa]

Thanks for the rely.

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

> 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
> 
> 

Re: [XHR]

[Tab Atkins Jr.]

On Wed, Mar 16, 2016 at 5:10 AM, Jonathan Garbee
 wrote:
> 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.
>
> If I understand correctly, streams [1] with fetch should solve this
> use-case.
>
> [1] https://streams.spec.whatwg.org/

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, 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.

(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.)

~TJ

Re: HTML5's Offline-first Council of Trent

[Anders Rundgren]

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.

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]

[Gomer Thomas]

  Hi Domenic,
  Thanks for your response. Please see my embedded remarks below 
(labeled with [GT]).
  Regards, Gomer
  --
  Gomer Thomas Consulting, LLC
  9810 132nd St NE
  Arlington, WA 98223
  Cell: 425-309-9933
  
  
  -Original Message-
   From: Domenic Denicola [mailto:d...@domenic.me] 
   Sent: Thursday, March 17, 2016 11:56 AM
   To: Gomer Thomas ; 'Jonathan Garbee' 
; 'Hallvord Reiar Michaelsen Steen' 

   Cc: 'WebApps WG' 
   Subject: RE: [XHR]
  
  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.
  [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.)  
  
  > (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?
  [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. Also, this is somewhat problematic as a measure 
unless the chunks are uniform in size. If the chunks are required to all be the 
same size, this greatly reduces the usefulness of the Streams concept. 
  
  > 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