3
edits
Talk:Browser History: Difference between revisions
no edit summary
(Sqlite locking problems on network drives) |
No edit summary |
||
| Line 1: | Line 1: | ||
=sqlite= | |||
I thought sqlite can't reliably do database locking when the database is stored on a network drive? See section 6.0 of http://www.sqlite.org/lockingv3.html. | I thought sqlite can't reliably do database locking when the database is stored on a network drive? See section 6.0 of http://www.sqlite.org/lockingv3.html. | ||
=fields in DB= | |||
Why not extend the list of saved attributes [[Browser_History#Database_design]] by the keywords that a lot of webservers send for a page (eg amazon)? This may enhance the probability to find the desired page when searching within the history. --[[User:Schoschi|Schoschi]] 17:54, 25 June 2006 (PDT) | |||
=tab?= | |||
Maybe we shall even save to history in which tab the page was displayed, thus enabling a query "I got to page XY from where I wanna go again now" even though I know perfectly well I visited dozens of sites in between - but in other tabs... Yea, right, this means tabs need unique IDs - shall not be the problem. I doubt source and resulting tabs produced by "open in new tab/window" clicks on links will be trackable with reasonable effort. --[[User:Schoschi|Schoschi]] 17:54, 25 June 2006 (PDT) | |||
=Understood right?= | |||
I'm not sure about that: Does saving ''every'' visiting time solve the common problem of a surf history like ''A -(link click)-> B -(back-button)-> A -(link)-> C'' and no way to get to B again? I mean using back/forward and - in cases of really bad luck - even history does not work out (currently). I do not know where to place this hint for the folks working on back/forward button functionallity so they do not forget it when the new history is implemented. --[[User:Schoschi|Schoschi]] 17:54, 25 June 2006 (PDT) | |||