Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
mozilla.dev.planning
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Places and Firefox 2
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Mike Shaver  
View profile  
 More options Apr 24 2006, 5:11 pm
Newsgroups: mozilla.dev.planning
From: "Mike Shaver" <mike.sha...@gmail.com>
Date: Mon, 24 Apr 2006 17:11:39 -0400
Local: Mon, Apr 24 2006 5:11 pm
Subject: Re: Places and Firefox 2
Print | View thread | Show original | Report this message | Find messages by this author
On 4/24/06, Benjamin Smedberg <benja...@smedbergs.us> wrote:

> Mike Connor wrote:
> > I'm less concerned with codesize than with shipping a stronger
> > platform.  There's also the strong possibility that we'll be supporting
> > a subset of the WHATWG local storage spec in Gecko 1.8.1, based on sqlite.

> Who is doing that work?

jst and Neil Deakin, it's already underway.  (See recent content team
minutes for more details, I expect.)

> I am wary of shipping complex platform-level features that do not get
> widespread "natural" testing, and have not received (IMO) sufficient
> targeted testing in the field. The SQLite performance issues that were
> turned up by the places work amplified my initial worry several times over.
> Since we are certainly not going to be freezing the storage interfaces for
> this cycle, I am very wary of shipping them or encouranging developers to
> use them.

Developers have been using the storage APIs for a long time now; since
the end of 2004 in calendar-land, and quite intensively with Places
since.  That testing is what led to the revisions in the APIs and also
the commissioning of the sqlite performance work (which preserved API
compatibility at the mozStorage level, I believe).

sqlite itself has been tested quite extensively -- the rest of our
platform should be so lucky! -- so the only other element here is our
wrapping of it in the mozStorage APIs.  Those APIs have had pretty
good testing proportionate to their scope, IMO.

I do not at all agree with the idea of not shipping things until
they're frozen.  We have a terrible record of "predictive" API design,
and not many groups have good ones.

> There are outstanding unresolved issues about how we plan to version the
> SQLite data structures over time within profiles (most of which are
> admittedly app-level issues, not platform-level issues),

They are app-level issues, and I don't think that "best practices"
here are going to emerge until after people try various different
approaches to it in the wild, in extensions, on top of our storage
interfaces.

> as well as
> questions about whether and to what extent we should be supporting
> multi-process access to the data.

"should be supporting" isn't as interesting as "will support", and for
Fx2 our answer will likely be "don't" or "at your own peril;
synchronize out of band".

Mike


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google