[rfe] allow for more flexible / customizable "group by day" groupings. bug #358784 will add nsNavHistory::GroupByDay(), which is used by the history sidebar to present the Fx 2 style "View | By Date" and "View | By Date and Site", but it's currently limited to only showing date by "days" and only showing eight buckets: "Today", "Yesterday", "2 days ago", "3 days ago", "4 days ago", "5 days ago", "6 days ago", "Older than 6 days". (which are all localized, see http://lxr.mozilla.org/seamonkey/source/browser/locales/en-US/chrome/browser/places/places.properties) but if an extension author wanted to write a alternative history sidebar that grouped "by date" differently (for example, like IE 7, see attached screen shot), it would not be easy to do that.

Is this worthwhile supporting extensions authors enhancing group by day? Does it add anything to the product? How likely is it that anybody would use this capability? I think you should just do it like IE out of the box (it's a little better than Firefox's current sidebar day grouping) and not worry about anything else.

> Is this worthwhile supporting extensions authors enhancing group by day? Does > it add anything to the product? How likely is it that anybody would use this > capability? good questions, I'm not sure the answer. > I think you should just do it like IE out of the box (it's a little better than > Firefox's current sidebar day grouping) and not worry about anything else. This is why I'd like the flexibility, so we could prototype IE style "group by date". As is, to do IE way would require C++ changes.

If you ask me, adding the ability to extend this grouping will be three times as much work and three times more complicated and overdesigned as changing the C++ code several times. The code for adding this feature in the first place was pretty simple.

It's hard for me to imagine what other groupings folks might come up with, but I strongly suspect that there are useful ways of grouping history that we haven't imagined yet, so making the grouping mechanism more flexible seems valuable. But whether or not to actually do it depends not only on its value but also the opportunity cost of doing so and its priority relative to other work.

> I think you should just do it like IE out of the box I think brettw has a valid point about IE's group by date vs Fx 2.0's group by date. I've logged bug #359346 about that. we'll keep this bug to track the discussion of group by date flexibility.

(In reply to comment #5) > It's hard for me to imagine what other groupings folks might come up with, but > I strongly suspect that there are useful ways of grouping history that we > haven't imagined yet, so making the grouping mechanism more flexible seems > valuable. Let me rephrase your question: "I'd like to be able to take a partially constructed query result, where the requirements of the current interface haven't been set up properly (because it's still being grouped), and add the necessary new COM interfaces, IDL files, documentation, and tests. Then I'd like to be able to ship that while thing off to Javascript, where date computations and URI parsing code will run on every single item in the user's history (because that's what the history sidebar contains), which will then get shipped back to the C++ code so that the query result can be returned. I would like to do this because, for reasons I can't think of right now, somebody will want to write an extension that makes the sidebar do something different that we program it to. " I'm sorry if I seem overly sarcastic or bitter, but I think the tendency to overdesign everything by orders of magnitude to support mystical undefined future uses has caused great harm to the Mozilla project.

(In reply to comment #7) > Let me rephrase your question: > > "I'd like to be able to take a partially constructed query result, where the > requirements of the current interface haven't been set up properly (because > it's still being grouped), and add the necessary new COM interfaces, IDL > files, documentation, and tests. Then I'd like to be able to ship that while > thing off to Javascript, where date computations and URI parsing code will > run on every single item in the user's history (because that's what the > history sidebar contains), which will then get shipped back to the C++ code > so that the query result can be returned. Well, my question didn't imply a particular implementation, but at first glance I'd say your suggestion in bug 359465, comment 3 sounds a lot better than the one you thought I was making here. > I would like to do this because, for reasons I can't think of right now, > somebody will want to write an extension that makes the sidebar do something > different that we program it to. " It's not the reasons I can't think of, it's the particular kind of grouping. The reason is that somebody comes up with a better way of grouping history which makes it more usable. Looking at it from another angle: we're clearly dissatisfied with our current UI, but we don't have solid evidence to support a particular alternative. IE7's implementation looks promising, and the idea of grouping history by session seems a good one (provided we can define what a session is), but we're still relative early in the process of figuring out what we want to do. Given that, it seems sensible to me to provide space for experimentation by architecting the feature to allow different kinds of groupings, subject of course to the constraints of opportunity cost, priority, performance, etc. > I'm sorry if I seem overly sarcastic or bitter, but I think the tendency to > overdesign everything by orders of magnitude to support mystical undefined > future uses has caused great harm to the Mozilla project. That may be true in a number of cases, but in others we've underdesigned to our detriment with layers of one-off hacks, hurting our own and others' abilities to develop and enhance our code and featureset. I've frequently run into such problems when developing extensions, including, to my chagrin, when extending my own code. But there's no simple principle by which to decide whether to hardcode or design for extensibility. We need to consider all the factors, and it may well be the case that repeatedly changing the C++ code, as you suggest in comment 4, is preferable to making grouping more flexible. But improving extensibility seems worth at least considering.

(In reply to comment #7) > > I'm sorry if I seem overly sarcastic or bitter, but I think the tendency to > overdesign everything by orders of magnitude to support mystical undefined > future uses has caused great harm to the Mozilla project. Agree. I think this would be a more meaningful discussion with concrete success criteria. I think there's value in writing C++ code to speed up common code paths that *we use*. But I have to wonder why we're spending time designing XPCOM interfaces for a relational database. Is there a part of the design that prevents ad-hoc SQL queries? If so, is it practical to make that go away for some or all use cases?

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.