On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp wrote:
> Indeed. Somewhat off-topic for this thread, but I think this "let's
> provide primitives and let other people build higher-level libraries"
> trend for Web platform features is pretty dangerous.
>
On the other hand, I think that the approach
On Mon, Jul 29, 2013 at 1:28 PM, Gijs Kruitbosch
wrote:
> On 29/07/13 21:53 , Anne van Kesteren wrote:
>> The current thinking is
>> that offering developers the primitives will give us a better higher
>> level API longer term.
>
> Isn't that reasoning part of why we are now in the position where
We desperately need to get a better offline story.
The counter proposal to this that I had is going to take a lot longer
to hammer out and get to a state where we can ship. Or rather, it'll
take longer to get to a point where we're confident it's not repeating
a lot of the mistakes of appcache-v1.
On Tuesday, July 30, 2013 8:16:48 AM UTC+12, Doug Turner wrote:
> My issue wasn't if we were going to work on the 'off-line' problem or
>
> not. It was mostly around stating we're going to implement
>
> prematurely. It might be I don't really understand what the "Intent to
>
> implement" bl
On 29/07/13 21:53 , Anne van Kesteren wrote:
The current thinking is
that offering developers the primitives will give us a better higher
level API longer term.
Isn't that reasoning part of why we are now in the position where we
have indexeddb and nobody uses it, instead preferring localstora
On Mon, Jul 29, 2013 at 1:16 PM, Doug Turner wrote:
> Do you think that NC is the right soluction here?
At a high level it seems like the kind of low-level API we want to
expose. The details are still muddy, we need implementation experience
and developer feedback for that.
> Anne van Kesteren
Implementation detail, but I presume that you will also replace the
existing appcache impl with NC, right?
Ehsan Akhgari wrote:
Offline not working seems like the #1 problem
of the web platform, so working on this API does not really feel
premature to me.
__
Do you think that NC is the right soluction here?
Anne van Kesteren wrote:
Offline not working seems like the #1 problem
of the web platform,
There are lots of problems with the web platform. Offline support is
one of them, yes. :)
so working on this API does not really feel
premature t
On 7/29/13 12:49 PM, Ehsan Akhgari wrote:
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote:
Given all the things that we could be doing instead, why is this
important to do now?
I share Benjamin's concern.
Legit concern. Probably low priority. I wanted to have a discussion on
it because I sus
On Mon, Jul 29, 2013 at 11:46 AM, Doug Turner wrote:
> I would feel much better if we "continued to monitor" this api and not rush
> here. Let Google do the rushing, lets implement later.
>
> Didn't Jonas have a proposal for the 'offline' use case?
We did discuss at the last meeting. This API is
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote:
Given all the things that we could be doing instead, why is this
important to do now?
I share Benjamin's concern.
Also, before we can discuss this, we need to make sure that every
Mercurial command handles bookmarks sanely. Last I checked, thin
On 2013-07-29 2:46 PM, Doug Turner wrote:
Intent to implement seems premature. Why wouldn't we wait to see how
this goes and let Google do that. I really dislike the idea of rushing
into this API.
What is the reason you think we should not implement this? We're not
exactly rushing into *shi
Intent to implement seems premature. Why wouldn't we wait to see how
this goes and let Google do that. I really dislike the idea of rushing
into this API.
A programatic API that does something like AppCache is a good idea --
only in that it is better than the declarative shit AppCache is. W
On 7/29/2013 1:43 PM, Gregory Szorc wrote:
I don't particularly care for our model of a single Mercurial
repository per logical entity. I think it makes sense for things like
twigs and to some extent integration repositories - you can do your
work in your own little world without disrupting oth
I don't particularly care for our model of a single Mercurial repository
per logical entity. I think it makes sense for things like twigs and to
some extent integration repositories - you can do your work in your own
little world without disrupting others. But for all the release
branches, I th
This will be going live tomorrow Tuesday 30th.
On 2013-07-23 4:38 PM, Armen Zambrano G. wrote:
I need these new changesets to spread across the FF25 trees before going
ahead with this:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4ab37e3f3e
https://hg.mozilla.org/integration/mozilla-
Our (ostensibly) weekly DOM bindings meetings continue on Monday July 29th
at 12:30 PM PDT.
Meeting details:
* Monday, July 29, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
- Vidyo room: Boris Zbarsky
- In office or soft p
We're moving the meeting 2 hours earlier!
8 AM in California
11 AM in Toronto and New York, etc.
16:00 in the UK and Portugal
17:00 in most parts of Europe
23:00 in Taipei
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meeting&iso=20130730T08&p1=224&am=30
Meeting Deta
>
> The Rendering meeting is about all things Gfx, Image, Layout, and Media.
> It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm
> PDT.
>
> The next meeting will take place today, Monday, July 29 at 2:30 PM US/Pacific
> The agenda is here: https://wiki.mozilla.org/Pl
On 7/23/2013 6:22 PM, Avi Halachmi wrote:
> TL;DR: Talos tsvg,tscroll are affected by timing much more than by rendering
> performance because they don't stress Firefox. tsvgx,tscrollx stress firefox:
> their results are different, better, noisier than the old tests. Will soon
> replace the old
20 matches
Mail list logo
