Re: HTML5's Offline-first Council of Trent

[Richard Maher]

Look Jake, your entire argument is premised on the abstract notion that “cached
data is often fine”. Allow me to respond with an equally unquantifiable
“EXCEPT WHEN IT BLOODY ISN’T”.



I’ve been cutting code for over 30 years and am very familiar with
scenarios where cached data is appropriate and if history is any guide it
tells us that server-level caching is the most effective (especially with
sophistication levels as high as Oracle’s cluster-wide Cache-Fusion). The
Fat-Client pattern came and went 20 years ago as far as I’m concerned but
if you, and others at W3C, are happy to breathe new life into the IBM 3270
[2] architecture by re-implementing it on the Web, then more power to you.
Those like myself who have gotten used to features such a server-hosted
character-by-character predictive-text, real-time banking, and trading, are
loathed to take such an enormous step backwards. You appear to have a
marvelous solution, but I and many others are not experiencing your
perceived problem(s).



The very real problem we are experiencing is the disproportionate resource
and funding allocation from browser vendors toward infrastructure and
functionality targeted at social-media. Not everything is Twitter and Email
for Pete’s sake or, for that matter, an RSS aggregation of this morning’s
newspapers.



Give us background GPS, give us some sort of broadcast/multi-cast Push API
capability without 1:1 notifications, just give us the tools to compete
with native apps and we’ll do the rest!



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, I’d like to introduce to you the latest
Web-App offering from HTML5 Horse-First Laboratories ™ [1]: -



*The Bud Fox Day-Trader App*



The true beauty of this Web App is that it doesn’t matter one iota what
time-zone you’re in as you can always buy and sell at a price that suits
your cache$ [4]



Wall Street may be closed, you could be going through the Channel Tunnel,
or you could simply be on the dark side of the moon, but BF Day-Trader will
let you buy or sell virtually straight from your stock portfolio!



*“But what if the current stock price is different to what I’m seeing and
trading in?” *



This is where Day-Trader shines above all the Native Apps that have to
submit to the laws of physics as well as the governance of the Securities
and Exchange Commission. Your trades don’t happen in real-time either! A
background-sync job will get around to transmitting your trade to the Stock
Exchange as soon as your network usage limits allow. By then the stock
price could well be what you bid for in the first place anyway. How good is
that!



In the words of our Systems Architect [3] “Close enough is good enough!”.



[1] http://images.clipartpanda.com/amish-clipart-68145_134_w11-14_s_lg.gif

[2] https://en.wikipedia.org/wiki/IBM_3270

[3] http://farm8.static.flickr.com/7278/7852694410_b2d8aa034c.jpg

[4]* Cache$ (Uselessness is relative concept)*



Cache$1 - This is the red-hot highly volatile repository for stocks that
you traded in the last week. Memory consumption is critical so less than
100 stocks are resident here and refresh rates can be almost hourly
depending on network availability.



Cache$2 – Overflow from Cache$1 into perpetuity.



IndexDB – At installation time every stock on the planet and last bid is
copied to your phone. Most DBAs will tell you that the best way to
replicate data is “not at all” but tell that to Thurston Howell III. You
just never know when you’ll have to trade from a deserted island.

On Tue, Mar 15, 2016 at 10:20 PM, Jake Archibald 
wrote:

> On Tue, 15 Mar 2016 at 12:14 Richard Maher  wrote:
>
>> Your willingness, nay preference, to serve up stale, outdated data, is an
>> exercise in self-flagellation that only a fellow sicko could understand
>>
> This is not the intent in the pattern you quote (
> https://jakearchibald.com/2014/offline-cookbook/#cache-then-network).
>
> The goal is to get cached data on screen then update it. This is because
> cached data is often fine as a first pass.
>
> If I'm going to my messaging app to remind me where I agreed to meet
> someone, cached data is fine. If I'm going to my fitness app to find out
> how long it took me to run two miles last week, cached data is fine. If I'm
> looking up the day for my flight, cached data is fine.
>
> But it doesn't stop there. The network is used, if available, to update
> both the content on the screen (in some non-disruptive way) and in the
> cache.
>
> The benefit of having data locally on the device is you don't need an
> internet connection to get it, if you refuse to show it until a network
> request as settled or timed out, you're throwing away the benefit.
>
> The offline-first pattern not only improves things for offline users, it
> improves things for everyone whose connection 

Re: Meeting for selection API at TPAC?

[Yoshifumi Inoue]

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

HTML editors meeting

[Léonie Watson]

Hello,

There will be an HTML editors meeting on 10 - 11 May 2016, at Microsoft in
Redmond. Info here:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/10-11mayHTML.md 

If you are interested in joining the HTML editorial team, we would like to
hear from you. Whilst anybody can submit a PR proposing a change to the HTML
spec, the editorial team is responsible for reviewing PRs and merging them
into the spec when they are ready.

Léonie.

-- 
@LeonieWatson tink.uk Carpe diem.

Re: HTML5's Offline-first Council of Trent

[Jake Archibald]

On Tue, 15 Mar 2016 at 12:14 Richard Maher  wrote:

> Your willingness, nay preference, to serve up stale, outdated data, is an
> exercise in self-flagellation that only a fellow sicko could understand
>
This is not the intent in the pattern you quote (
https://jakearchibald.com/2014/offline-cookbook/#cache-then-network).

The goal is to get cached data on screen then update it. This is because
cached data is often fine as a first pass.

If I'm going to my messaging app to remind me where I agreed to meet
someone, cached data is fine. If I'm going to my fitness app to find out
how long it took me to run two miles last week, cached data is fine. If I'm
looking up the day for my flight, cached data is fine.

But it doesn't stop there. The network is used, if available, to update
both the content on the screen (in some non-disruptive way) and in the
cache.

The benefit of having data locally on the device is you don't need an
internet connection to get it, if you refuse to show it until a network
request as settled or timed out, you're throwing away the benefit.

The offline-first pattern not only improves things for offline users, it
improves things for everyone whose connection to the internet is slower
than their device's storage.

HTML5's Offline-first Council of Trent

[Richard Maher]

I was going to post this as a reply to #844
 (*) but this
topic is a far greater and more of an all-encompassing issue than any
single thread can serve.

We (all HTML5 Web-App developers) desperately need a schism from the
heretical forces of "Offline First" and the Spartan, austere, featureless
world, of Web-App minimalism!

If you want to hamstring yourselves and live a primitive
pre-telecommunications lifestyle, or something more akin to life post
Road-Warrior Apocalypse, then good for you; just stop white-anting people
who wish to take full advantage of modern technology!

For most "cashed-up" consumers, Lack of Connectivity is the exception an
NOT the norm. (And I live in the most isolated capital city in the world so
cop that!) Sure we'll failback and degrade gracefully but we WILL NOT
target the bean-tins-and-string deployment option.

Your Client-Based GeoFences are a joke :-( Your willingness, nay
preference, to serve up stale, outdated data, is an exercise in
self-flagellation that only a fellow sicko could understand.

But let us wicked technologists not sway you from your
life-was-meant-to-be-hard, God-would've-given-us-wings fanaticism. All we
want is a fair share of the Chrome, Mozilla, Opera, and Safari development
budgets for expanding the Feature List rather than censoring it.


(*) The reason I was quoting that thread is that it used to contain the
following: -


 > Although we're using a timeout, this approach still suffers from being
online-first. A better approach is offline-first
https://jakearchibald.com/2014/offline-cookbook/#cache-then-network
Drives me absolutely insane :-(

RE: Telecon / meeting on first week of April for Web Components

[Léonie Watson]

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 weeks
in advance [1]. Let me know the date(s)/venue, and we can do that too.

Léonie.
[1] https://lists.w3.org/Archives/Public/public-webapps/2016JanMar/0043.html


> -Original Message-
> From: rn...@apple.com [mailto:rn...@apple.com]
> Sent: 14 March 2016 23:56
> To: t...@tink.uk; Chaals McCathie Nevile 
> Cc: public-webapps 
> Subject: Telecon / meeting on first week of April for Web Components
> 
> Hi all,
> 
> We've been making a good progress on shadow DOM and custom elements
> API but there seems to be a lot of open questions still.  I've asked a
couple of
> people involved in the discussion, and there seems to be an interest for
> having another tele-conference or an in-person meeting.
> 
> Can we schedule one in the second week of April (April 4th through 8th)?
> 
> - R. Niwa

RE: Telecon / meeting on first week of April for Web Components

[Léonie Watson]

Would a meeting at TPAC be useful too? It’s 19 to 23 september, in Lisbon 
Portugal.

 

We need to request meeting space by the end of this month. So if so, let us 
know how much time you think you’ll need, and roughly how many people you think 
might attend.

 

Thanks.

Léonie.

From: Dimitri Glazkov [mailto:dglaz...@google.com] 
Sent: 15 March 2016 04:30
To: Ryosuke Niwa 
Cc: Léonie Watson ; Chaals McCathie Nevile 
; public-webapps 
Subject: Re: Telecon / meeting on first week of April for Web Components

 

I am game, per usual.

 

:DG<

 

On Mon, Mar 14, 2016 at 4:55 PM, Ryosuke Niwa  > wrote:

Hi all,

We've been making a good progress on shadow DOM and custom elements API but 
there seems to be a lot of open questions still.  I've asked a couple of people 
involved in the discussion, and there seems to be an interest for having 
another tele-conference or an in-person meeting.

Can we schedule one in the second week of April (April 4th through 8th)?

- R. Niwa



 

Re: Telecon / meeting on first week of April for Web Components

[Hayato Ito]

Though I'm afraid that I can not attend the in-person meeting in April, I
can join remotely, per unusual.

On Tue, Mar 15, 2016 at 1:35 PM Dimitri Glazkov  wrote:

> I am game, per usual.
>
> :DG<
>
> On Mon, Mar 14, 2016 at 4:55 PM, Ryosuke Niwa  wrote:
>
>> Hi all,
>>
>> We've been making a good progress on shadow DOM and custom elements API
>> but there seems to be a lot of open questions still.  I've asked a couple
>> of people involved in the discussion, and there seems to be an interest for
>> having another tele-conference or an in-person meeting.
>>
>> Can we schedule one in the second week of April (April 4th through 8th)?
>>
>> - R. Niwa
>>
>>
>>
>