"Places in SeaMonkey 2.0

Paul · Post by **Paul** » November 21st, 2007, 8:28 pm

I have heard that "Places" which is planed to replace History and Bookmarks in FF 3.0 may be migrated (in whole or just parts of places) in SeaMonkey 2.0 or another future release replacing history and bookmarks in SeaMonkey. I have a few questions/conerns about this change which mainly arise because I do not know a lot about "Places" as it will be implemented in FF. So if places is implemented in whole or in part will:

1. SeaMonkey keep the sidebar for displaying bookmarks. I keep the sidebar open to bookmarks all the time and would greatly miss this feature.

2. I have heard comments from some SeaMonkey users/developers that they do not like the Places UI implementation for FF. What is it about this UI that is not liked? Is there a screenshot oneline to show what this UI looks like?

3. Will SeaMonkey adopt places as implemented for FF 3.0? Will SeaMonkey end up with a very different bookmarking system? (I hope not as I love the ability to keep bookmarks open in the sidebar.)

One major reason I use SeaMonkey is that I love the sidebar. Please can someone expand on the future plans for the management of History and Bookmarks in future releases of SeaMonkey. Thanks.

raj_bhaskar · Post by **raj_bhaskar** » November 22nd, 2007, 2:28 am

You can find out more about Places on the Mozilla wiki. There's a lot of stuff there, but it seems that there's two bits: the front end and the backend (which replaces the existing bookmarks/history with a unified back end using MozStorage). It's possible that SM might use the Places backend and either keep the existing front end or modify the Places front end to stay in keeping with the SM look and feel. But I'm not a developer and am only going on what I read on the web.

BenoitRen · Post by **BenoitRen** » November 22nd, 2007, 7:22 am

They will use the backend, but they will not change any UI.

Philip Chee · Post by **Philip Chee** » November 22nd, 2007, 12:22 pm

BenoitRen wrote:but they will not change any UI.

Yet. Some of the URLbar improvements may be backported I think.

Phil

RDaneel · Post by **RDaneel** » November 22nd, 2007, 1:03 pm

Keeping the [current] UI seems to be popular with SM users - since the UI is one of the reasons they *are* SM users.

I have heard [so far unsubstantiated] claims that Places is a resource hog... could someone that knows something about Places comment on this, and further, just what real problems in the SM codebase would it address?

Or is it just the next shiny thing that some devs are salivating over (not that there is anything wrong with shiny things per se)?

Philip Chee · Post by **Philip Chee** » November 22nd, 2007, 1:52 pm

RDaneel wrote:just what real problems in the SM codebase would it address?

Well for one performance of the history backend. Currently the Mork database engine is:

1. Relatively unmaintained.
2. The code and structure is insane so nobody understands how it works (see #1).
(The person who designed Mork writes all his usenet posts in haiku).
3. A performance hog once your history file gets larger than a certain size.
4. And nobody wants to work on Mork to improve it's performance (See #2).
5. Places is a resources hog, but only to those people who haven't looked at the Mork code and ran screaming away in terror (See #4 and #2).

Phil