Re: Browser Architecture Newsletter 5

[Richard Newman]

>
> We have quite a bit of ongoing activity linked from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1147820 focused on APIs
> exposed to web content (HTTP cache, cookies, localStorage, Indexed DB,
> service worker registrations, etc.) and the associated UI exposed to
> users. There should maybe be a discussion at some point if the backend
> can be reconciled somehow…
>

If you'll be at the All Hands, we'd love to talk about this at one of the
two storage-related meetings that are in Sched. Come along!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Browser Architecture Newsletter 5

[Gregory Szorc]

> On Nov 30, 2017, at 04:40, Anne van Kesteren  wrote:
> 
>> On Wed, Nov 29, 2017 at 9:47 PM, Dave Townsend  wrote:
>> If you’re working on improving storage or syncing of data in any of our
>> products or projects, on any platform, or if you’re currently struggling to
>> work with what currently exists, then we’d like to hear from you and align
>> our efforts.
> 
> We have quite a bit of ongoing activity linked from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1147820 focused on APIs
> exposed to web content (HTTP cache, cookies, localStorage, Indexed DB,
> service worker registrations, etc.) and the associated UI exposed to
> users. There should maybe be a discussion at some point if the backend
> can be reconciled somehow as I think it would be beneficial to users
> if at some point some or all of this data could be synchronized in the
> same manner bookmarks are today. (No reason to "install" a web
> application twice or not having access to locally stored documents if
> the user agent can just synchronize the necessary data for you.)

This all sounds reasonable to me.

In addition, I’d also suggest that syncing considerations be taken into account 
as part of web standard design. Having worked on multiple “sync” products 
(including Firefox Sync), I’ve seen what happens when syncing is an 
afterthought. Just like security, you can’t just bolt syncing onto an existing 
product/feature: it needs to be considered as part of the initial design in 
order for the final implementation to be high quality.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Browser Architecture Newsletter 5

[Anne van Kesteren]

On Wed, Nov 29, 2017 at 9:47 PM, Dave Townsend  wrote:
> If you’re working on improving storage or syncing of data in any of our
> products or projects, on any platform, or if you’re currently struggling to
> work with what currently exists, then we’d like to hear from you and align
> our efforts.

We have quite a bit of ongoing activity linked from
https://bugzilla.mozilla.org/show_bug.cgi?id=1147820 focused on APIs
exposed to web content (HTTP cache, cookies, localStorage, Indexed DB,
service worker registrations, etc.) and the associated UI exposed to
users. There should maybe be a discussion at some point if the backend
can be reconciled somehow as I think it would be beneficial to users
if at some point some or all of this data could be synchronized in the
same manner bookmarks are today. (No reason to "install" a web
application twice or not having access to locally stored documents if
the user agent can just synchronize the necessary data for you.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Browser Architecture Newsletter 5

[Dirkjan Ochtman]

Hi,

The coherent thinking and communication about Browser Architecture is a
really good change from before, thanks for that.

On Wed, Nov 29, 2017 at 9:47 PM, Dave Townsend 
wrote:

> We’ll be meeting to talk in more detail about the roadmap, the present,
> and the future at the All Hands
> . We
> would welcome your participation.
>

After reading the roadmap doc, I have one question: is anyone thinking
about Sync/Storage beyond the browser? It seems Sync and Storage,
especially for those of us who use smartphones or tablets, are an integral
part of modern life, yet these services are largely proprietary, and many
do not come with substantial privacy guarantees. As part of the Mozilla
mission, would it be crazy to ask that at least the fundamental
architecture of a Sync redesign takes non-browser (for example, files,
email, contacts and calendars) into account?

Best regards,

Dirkjan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Browser Architecture Newsletter 5

[Dave Townsend]

Welcome to the exciting fifth instalment in our series of Browser
Architecture Newsletters!

Storage and Sync

We are pleased to report that the Sync and Storage roadmap proposal
successfully passed review by dcamp. Thanks to the 20+ people from around
the organization who helped us build consensus.

The roadmap establishes that storage and syncing of user data is a pillar
of the Firefox ecosystem, warranting holistic and long-term attention, and
outlines both where we’d like to end up and some ideas for how to get there.

We expect this roadmap to lead to a number of subsequent concrete design
reviews, as we begin with prototyping, further competitive analysis, and
more coordination across Mozilla. The roadmap doc itself has been lightly
cleaned up and published

alongside our other docs
.

If you’re working on improving storage or syncing of data in any of our
products or projects, on any platform, or if you’re currently struggling to
work with what currently exists, then we’d like to hear from you and align
our efforts.

You can find us in Slack or IRC (#browser-arch), or come find rnewman,
etoop, rfkelly, markh, or adavis.

We’ll be meeting to talk in more detail about the roadmap, the present, and
the future at the All Hands
. We
would welcome your participation.

XBL Removal

Our work to remove XBL is proceeding apace. We’ve started by removing
bindings that are never or only rarely used. Work to convert XBL bindings
to custom elements is currently stalled while we get custom elements
working in XUL.


You can track how this project is progressing with some lovely graphs
. If you’d like to help with
the effort, you can grab a bug tagged with [xbl-available]
.

Workflow Improvements

Running mochitest-plain in headless mode is now supported on Windows,
MacOS, and Linux. Use the “--headless” flag with “./mach test” to try it
out.

Austin All Hands

We have two meetings planned for the All Hands. You can see these in Sched
here:

Austin Y'all Hands 2017: Sync and Storage


Austin Y'all Hands 2017: XBL and XUL Removal

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform