467157 - add history retention rules and improve searchability

Status: RESOLVED WONTFIX

(SeaMonkey :: Bookmarks & History, enhancement)

Description

[quartz12h]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12

Here is the list of features I would expect from a good history mecanism:

a) deeper than 6 days classification. I clean up hosts I don't want to keep
every weekend, but that is 7 days, so the 'older than 6 days' bucket is hard to
filter out. It should simply be a config point in the prefs (30 days classes
for example). Don't forget there is sql lite in the back (at least in the firefox code base, which I assume seamkonkey will import eventually), so it is pretty powerful when using sql "group by", "order by" and sharp "where" clauses.

b) I would love that once you group by host, you could sort by url count in
that host. It would help cleaning up fat and lean groups. In fact, given any
grouping type, give the count in a discrete value and allow to sort.

c) I know I keep all my imdb and wikipedia visited links, because it helps
showing that I already read some web page. I never want these to roll off
(until a 2 years threshold maybe...). I would want a whitelist/blacklist to
enter the history. This is also good to get rid of the neverending list of
google urls...

But when you think about it, ultimately, it boils down to giving a time-to-live
to a url in the history associated to a matching rule. Example:

*google.com/* -> TTL = 1 day (just enough to recall a search)
*imdb.com/* -> TTL = 999 days.
forums.foobar.com/* -> 15 days.
DEFAULT -> <whatever> days.

Implementation wise, it is not exactly a TTL value in the db schema but rather
an expiration date and an index on that column in the table (so that rolling
off , on browser start I guess, but only once per day, remains quick).

This is a spinoff from bug #223476.



Reproducible: Always




Feel free to move this to firefox if seamonkey has no intention of leaving mork for sqllite (in which case I would leave too...sadly).

Comment 1

[Daniel Mota Leite]

a external program to manage/setup the TTL of the history maybe would be a good idea, the SQL like would only need to have a extra field with the configured TTL, firefox would use the default, any change  made by the external would be valid and both could do the cleanning

this way no one would protest about bloating firefox and people could setup this rules

Comment 2

[Tony Mechelynck [:tonymec]]

I suppose it's too late to implement this on the "old-style" history backend, so moving to Trunk and set Depending on bug 382187 (which is about using Places, i.e. the new-style sqlite backend, for SeaMonkey history).

Comment 3

[quartz12h]

I would hope that fthe "deeper than 6 days classification" fix is feasibile on the old-style, since it is only a UI change (right?).

Comment 4

[Robert Kaiser]

For one thing, this bug is confusing as it's about multiple different feature enhancements, parts of which are UI, parts of which are backend stuff.
For the other, these are no high-priority feature for SeaMonkey 2, so the wanted flag doesn't apply.

Comment 5

[Bruno 'Aqualon' Escherl]

Can you please open new bugs for each of your suggestions (ideally look for similar bugs already filed before), because they are different issues. But these may be better suited for an extension.

Comment 6

[[e-mail]]

(In reply to comment #3)
> I would hope that fthe "deeper than 6 days classification" fix is feasibile on
> the old-style, since it is only a UI change (right?).
It would have been feasible, yes, but SeaMonkey 2.0 has switched to Places which gives us the monthly buckets automatically.

Comment 7

[Phoenix]

So, as Neil pointed, a) is already implemented, b) as grouping by website and ability to delete by domain from context menu too, for c) I propose wontfix as this now can be achieved with grouping by site and don't touching imdb and wiki groups

Comment 8

[Phoenix]

Resolved per whiteboard