As we have been preparing for the FF2 Alpha2 on May 9 it has become
increasingly clear that we do not have time to complete an
implementation of places that lives up to our standards of user
experience and quality.   Places is a complex and exciting feature which
changes the way people use bookmarks, history, and navigate through
their private space of the web.   Rather than rush it to market - we'd
prefer to spend the time it takes to get it right.

Thus, we are going to disable Places on the 1.8 branch and continue work
on the feature on the trunk for inclusion on a future release.   This is
a difficult decision - but doing it this early in the release cycle
gives us the time to focus on delivering an extremely high quality FF2
in Q3 and gives Places the room it needs to develop into a truly
innovative feature.

To be clear - we're still focused on delivering Places as a truly
compelling end user feature in a future release.  We're also confident
that the other features and enhancements slated for FF2 will provide a
great upgrade for 1.5 users and continue to be a compelling browser
choice for new users.  Firefox 2 will improve security, tabbed browsing,
search, RSS/structured content discovery, performance, and extension
support.  In order words, all the reasons people love Firefox will get
demonstrably better in this release.

At the Bon Echo meeting Tuesday at 11am we'll do a more in-depth review
of status of every feature area to figure out what else is at risk and
make sure we have all available effort focused on the critical areas.
So come prepared to talk about your feature area and plan for a longer
meeting than normal.

Cheers,

Schrep

On 04/24/06 01:00, Michael Schroepfer wrote:

Without Places, Firefox 2.0 will have nothing new. Security
improvements, making the tabbed browsing UI worse ( :-P ), the search
XML backend and manager thingy, improved feed discovery, performance and
extension support... That's nothing. Even Places isn't very much, if
you're only thinking about the frontend as most users will. Users are
going to be extremely disappointed when they see nothing new or interesting.

mozilla.feedback has "I don't see any big differences" repeated
frequently over 2.0a1, and it had Places. From your post, Firefox 2.0
sounds like it should be called Firefox 1.6.
--
Matt Nordhoff
(aka Peng on IRC & the forums)

On 04/24/06 04:27, Matt Nordhoff wrote:

Wait, are session restore and the in-line spell checking still going to
be in 2.0?

If they are, I'll be okay with 1.7, but still not 2.0. They aren't an
immediate "Wow!" when you open the browser.

(And yes, I know I'm being harsh, and even small improvements are a good
thing and can take a good amount of work, but Firefox 2.0 just doesn't
seem like a 2.0.)
--
Matt Nordhoff
(aka Peng on IRC & the forums)

On 04/24/06 04:57, Matt Nordhoff wrote:

Okay, I retract my nastiness, but I still think that without Places,
Firefox 2.0 is somewhat disappointing. But then, most of the other
things don't really matter to me. Well, security and performance and
extension support do, but I don't have problems with them (except the
slowness of my huge amounts of bookmarks and history).

The session restore feature, I already use Session Manager and will
continue to, because the extension can be updated without the review
process and I can easily get those updates without having to download a
new build of Firefox.

The search stuff is nice, too. Using the XML format reduces the number
of files I have in searchplugins by half, and the format looks nicer
than the old one. (And importing them will make all the indentation and
stuff identical in each one. :-) )

And Places, well, at least it will be interesting. I'm back down to the
mozilla1.8.0 branch because I want to avoid it until it's fully working
and I've sorted out my duplicate bookmarks because Places'll screw 'em
up, but once I do that and have an hour or two where I can live without
being able to use Firefox while everything is imported, I'm game.

Meh. Whatever. I'm rambling more, but at least I'm being nicer. ;-)
Firefox 2.0 isn't seeming incredibly interesting, though.
--
Matt Nordhoff
(aka Peng on IRC & the forums)

Yeah I'm all for this. Places has loads of potential that i'm sure will
get realised, but atm there's too many bugs filed against it in order
to give end users a highly polished experience for 2.0.

2.0 will still have a bunch of improvements, including:
    * Visual Refresh
    * Safebrowser anti-phising
    * Inline spellcheck
    * Session Management
    * RSS handling improvements
    * Extension/Themes UI change
    * New search engine infrastructure and UI
    * New installer
    * Browser performance metric measurer
which is quite a few, and most of them something the end-user will be
able to see with their own eyes. Some ppl might say this isn't enough
to be worth calling it a 2.0 release, but for me it is, and a 2.0
release doesn't have to be a much-trumpeted affair.

What if you want to stack your browser advances up against the other
next-generation browsers soon to be released:  IE7 and Opera9?

I don't know, going up a rev number is usually a big deal.  I guess if
you put all total advances from 1.0 -> 2.0 it is a big deal.  So now I
see why edging the release number from 1.1 to 1.5 last year was a wise
choice, because the step to 2.0 is not exactly earth-shattering.  Only
problem is, it's been so long since I used Firefox 1.0 that I kind of
forget the advances that Firefox 1.5 brought.

Anyway, it's not like people are not going to upgrade (especially with
the auto-upgrade functionality in 1.5)... there will just be less of a
fuss in the blogosphere (and prepare yourselves for a few
"disappointed" reviews).  Heck, Firefox 1.5 still beats IE7, from what
I've heard...

Hey, maybe they can get those recently checked-in SVG performance
improvements into 2.0...;)

Will Firefox 2 ship the mozstorage (sqllite) engine then?  It might be
worth it for extension authors to have it, even if the main product
doesn't use it.

Doron

Yes, the plan is still for mozStorage to ship with Fx2 so that it's
available to extension authors.  This should give a much nicer
alternative to RDF/XML for data storage.

How was that decided? Part of the codesize tradeoff for sqlite was the
removal of the full mork engine. Shipping both sounds like a silly idea
since the app won't be using sqlite at all (unless there are other
dependencies that I've missed).

--BDS

Out of curiosity, how was this decision made?  I would have thought
there would have been some discussion about it in this newsgroup and the
weekly meetings, but I don't recall any such discussion taking place.

-myk

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.

-- Mike

Who is doing that work?

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.

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), as well as
questions about whether and to what extent we should be supporting
multi-process access to the data. Unless there is a Firefox 2 feature that
requires the storage APIs, I do not think that "a stronger platform" is a
good reason to ship this code.

--BDS

Weird, I hadn't heard that this would be a possibility on any of the
planning meetings summaries or in the Firefox 2 Requirements wiki page.
 What priority was that?  In fact, seems that almost all the Places
stuff was P1 (i.e. Mandatory) and the Release Criteria states "all P1
product requirements are complete"...

We need to decide soon about sqlite being in or out. We need to change
some of the APIs around and make some things safer. If it's shipping in
2.0, I need to make this a priority. Otherwise, it will stay on the back
burner.

I would come to exactly the opposite conclusion you have. Places
performs fine now, in some ways better than Mork. Any system requires
tuning to perform well. The previous history system no doubt had a lot
of performance work done on it to make it fast, and sqlite is no
different. I don't see this as a warning sign at all. (Perhaps some of
this feeling is a result of the early impression that was floating
around that sqlite would solve all our problems, which is clearly not
true.) We have produced a system that has been tested it to perform well
under constant use while you browse.

I would also like to see this discussion take place. At least we need a
plan, even if we don't actually do anything.

 > as well as

The decision is that we don't support this. Supporting it would kill a
lot of the performance. Maybe this decision wasn't made explicitly, but
it will take a lot of work that hasn't been planned and would give a
measurable performance hit no matter what, so I think the decision has
been made implicitly.

Brett

On 4/24/06, Benjamin Smedberg <benja...@smedbergs.us> wrote:

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

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.

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.

"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

What I think:

- Angst about Firefox 2 lacking a reason to exist without Places,
especially vis a vis IE7, is misplaced, if you will pardon the pun.
There are tons of good reasons to do a strong Firefox 2 upgrade to 1.5
this year, well before IE7 comes out -- some of these have already been
listed in this thread by others.

- Local storage based on the http://www.whatwg.org/ proposal should be
in Firefox 2.  It wasn't planned early, but it looks like it will fit
easily, and the reward is big while Firefox can differentiate itself
against IE6.  Again, Firefox 2 has a place in the stream of releases we
will make over the next few years in order to compete and to advance the
state of the open web.  Making Firefox 2 all about Places is a mistake.

- There are other platform pieces being uplifted into Firefox 2, about
which shaver has led the planning.  I'll let him jump in here.

While we should not be over-focused on IE7, the idea of sandwiching IE7
between continuously improving Firefox releases still wins over trying
to do one "big-bang", "matching" release.

More than any competitive strategy, it is vitally important that we
continuously improve the product and the platform soon and regularly.
Right now Firefox has >50% usage on "web 2.0"-ish sites.  That market
share is pure leverage, which we should use to (a) keep improving user
and content author experiences; (b) keep the competition on *their* toes
-- which we are doing!

Avoiding all-or-nothing thinking, and big-bang mythical-man-month
last-minute-fix moves, are also Good Things (tm).  Taking the time
needed to get Places right, adjusting the Firefox 2 bill of materials,
keeping on schedule, all shows mature judgment and realism.  Huzzah to
all that -- we need more of it.

/be

I didn't say that... I said "shipping things that we're not also going to
use internally". There is a much higher incentive to keep backwards
compatibility or provide compatibility workarounds as the code matures if we
are using the code internally and it's "our problem".

Sure, and expediency is a fine plan if you actually are planning on using
the feature, which was the general agreement six months ago when we decided
that we didn't have time to think about multi-process SQLite access for FF2.
But (modulo local-storage APIs) we don't have to bite that bullet, which
gives us the extra 3-6 months before FF3 closes to see if we can come up
with a good sharing solution before we're committed to a file format,
locking pattern, and API.

--BDS

On 24 Apr 2006 13:49:12 -0700, schiller <codedr...@gmail.com> wrote:

http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-04#Infrastruc...
mentioned it, and
http://wiki.mozilla.org/Firefox2/StatusMeetings/2006-04-11#Infrastruc...
as well, plus the content meeting minutes from
http://groups.google.com/group/mozilla.dev.platform/browse_frm/thread...

It hasn't had an explicit priority set, we're still in the
"investigative initial development" stage.  Is that important?

So?  Are you trying to say that we are in violation of some contract?
Many items have had their priorities adjusted as we learned more about
them or considered the tradeoffs further, as is the case for virtually
every piece of software I've ever worked on.

If you're just pointing out that the priorities changed, and that what
we once thought was going to be central to Firefox 2 is no longer
something we're comfortable holding the release for, then you're just
repeating what Schrep posted to start this thread.

It would be helpful, possibly, for you to finish the sentence, since I
don't think the ellipsis is clear enough to make your point plain.
(It's not to me, at least.)

If you have input on the prioritization of Fx2 elements, please do
join us on the weekly call tomorrow to share it, or add it to the
agenda page beforehand.

Mike

On Sunday 2006-04-23 22:00 -0700, Michael Schroepfer wrote:

So, what's going to happen to the portion of our testing community that
has migrated their primary profiles to places-based storage?  Will they
just lose all the changes they've made to their bookmarks since the
switch to places?  When we switch back to places, will they lose all the
changes they make from now until then?

We don't want to make things too painful for our bleeding-edge testers
or pretty soon we won't have any.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

Gecko 1.8.1 features are separately tracked from the Firefox 2 app
planning.  It is not a requirement from the application end, other than
the generic item for Gecko 1.8.1 uplift and improvements.

Well, the conversation around that was "if we're doing Places in this
release, we need all of these things for it to be done" which is why
they were all P1s.  If something turns out to be too risky, in terms of
stability and/or schedule impact, we need to reassess things. The
requirements will evolve and change for any release based on what is
possible and what is not, at that point in time.  Features and their
importance are relative to release dates, and we based the feature list
around a Q3 release.  With a possible slip until next year to get Places
up to the right level of quality in Fx2, and a planned Q1 release for
Firefox 3, moving the feature to Firefox 3 isn't a big change in when
the feature should get to market, it just means others will get there
earlier.

-- Mike

On 4/24/06, L. David Baron <dba...@dbaron.org> wrote:

If we do nothing, then they will "lose" any changes they made to their
bookmarks since running a places-enabled build.  That may be a pill we
should swallow for simplicity sake.  Going back to places, we can make
matters better by renaming the "history and bookmarks" sqlite file.

-Darin

Given that there isn't an exporter, those recent bookmarks won't be
accessible in branch builds.  If they're following the branch, they've
quite possibly had to nuke their sqlite file a couple times to make
stuff work right (I actually need to bite that bullet myself), so its
nothing really new.
 Best case, someone could write an exporter soon, and they could run
that from a trunk build...

Agreed in principle, but I'm not sure what you're saying we should do
here.  Write a sqlite->html converter and ship that in the non-places
builds?  There's only so much we can do here, its just going to suck for
some people, but they can always run a trunk build and recover that
bookmark, its not like the date is _gone_.  They can at least drag the
bookmarks to Notepad or something and get the URLs.

-- Mike

On 4/24/06, L. David Baron <dba...@dbaron.org> wrote:

I believe the Places bookmark-export code has just landed, or is
reviewed and is ready to land, so that problem may be lessened.

Mike
(I could be totally wrong, though)

_Mike Shaver_ spoke thusly on 24/04/2006 5:51 PM:

https://bugzilla.mozilla.org/show_bug.cgi?id=318057
https://bugzilla.mozilla.org/show_bug.cgi?id=327925
--
Chris Ilias
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)

Yeah, it's landed on trunk and 2.0 branch:
https://bugzilla.mozilla.org/show_bug.cgi?id=318057 --
[Firefox:Places]-bookmarks.html exporter [All]