-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: browser-history instructions missing #339
Comments
For 1, you should use Can copy over the example part of the readme:
For 3, after |
Yeah, I've been meaning to switch promnesia to use https://github.com/seanbreckenridge/promnesia/blob/master/promnesia_sean/sources/browsing.py |
…wserexport later will rename to browser, and implement defensive fallback onto browser_old adapted from https://github.com/seanbreckenridge/promnesia/blob/master/promnesia_sean/sources/browsing.py related: #339 Old vs new modules produce almost identical results (tested on various chrome & firefox databases) There are some minor differences vs the old module: - old database timestamps end with +00:00 UTC, new ones with +00:00 -- likely because browserexport is using timezone.utc instead of pytz - previously locator was pointing at the database file, now it's pointing at the URL I guess it's not necessarily in the 'spirit' of locator field, but on the other hand, not that it's very useful to point to an sqlite file either. Perhaps later it could be in some sort of extra debug field instead.
…wserexport later will rename to browser, and implement defensive fallback onto browser_old adapted from https://github.com/seanbreckenridge/promnesia/blob/master/promnesia_sean/sources/browsing.py related: #339 Old vs new modules produce almost identical results (tested on various chrome & firefox databases) There are some minor differences vs the old module: - old database timestamps end with +00:00 UTC, new ones with +00:00 -- likely because browserexport is using timezone.utc instead of pytz - previously locator was pointing at the database file, now it's pointing at the URL I guess it's not necessarily in the 'spirit' of locator field, but on the other hand, not that it's very useful to point to an sqlite file either. Perhaps later it could be in some sort of extra debug field instead.
…wserexport later will rename to browser, and implement defensive fallback onto browser_old adapted from https://github.com/seanbreckenridge/promnesia/blob/master/promnesia_sean/sources/browsing.py related: #339 Old vs new modules produce almost identical results (tested on various chrome & firefox databases) There are some minor differences vs the old module: - old database timestamps end with +00:00 UTC, new ones with +00:00 -- likely because browserexport is using timezone.utc instead of pytz - previously locator was pointing at the database file, now it's pointing at the URL I guess it's not necessarily in the 'spirit' of locator field, but on the other hand, not that it's very useful to point to an sqlite file either. Perhaps later it could be in some sort of extra debug field instead.
@karlicoss if you'd like, I can make a PR with some instructions for using browserexport here. Should that go in |
@seanbreckenridge thanks, of course would be appreciated! |
Given the opportunity, browsers forget their history pretty soon, and extending the history span is the most precious artifact of promnesiq for me. I would like the instructions to explain in detail how not to lose one accumulated history elements, when updating. And whether duplicates and overlaps are dropped. Forgive me is what I'm saying doesn't make sense. |
No, that makes sense @ankostis ! Worth mention why even bother with setting up a promnesia module if the extension can work with local browser history directly. Promnesia itself isn't dealing with browser history backups etc though -- so I guess the instructions will link to more detailed instructions in https://github.com/seanbreckenridge/browserexport#usage |
Duplicates in this case would use the timestamp as part of the unique check, so whenever a new database is backed up to your local data directory (e.g. Just as an example (I havent switched to the new browser module yet, so ignore the |
I guess if you use active_browser (I haven't set it up yet), you'd have duplicates in the extension coming both from the backend and from the local browser history API (if they have different source names). Maybe worth doing some frontend changes to handle that |
Ah, that is true... even |
I noticed that browser-history instructions are completely absent from
SOURCES.org
, so I could provide a MR (if i figured how to do it:-)).Would it suffice to do the following:
run some this browserexport commands (which ones??)
configuring the respective HPI MODULE, and
somehow (?) instructing promnesia to hook from the above HPI SOURCE.
Another Q regards the old txt files, generated by the deprecated-script: how to also parse them into a unified browser history?
The text was updated successfully, but these errors were encountered: