On 4/18/21 11:16 AM, Jean-Francois Dockes wrote:
David King writes:
> I have not found a recoll web caching plug-in for Google Chrome? Is
> there one? Are there plans to develop one?
I think that I gave a try to running the Firefox extension in Chrome after the
initial
conversion from the old Firefox API, and it almost ran but not quite, and I did
not try after the most recent changes. There is nothing else as far as I know.
> I've done a proof-of-concept for my own use by modifying the existing
> Firefox plugin to make it work in Chrome.
>
> What I've got right now is definitely not ready for prime time. I'm
> curious if there is any interest in polishing up and integrating in what
> I've done? It's not standalone, it would have to be integrated into the
> code that JF supports.
I think that it would be nice to have a Chrome version of the plugin. There are
not many users of the Firefox extension, but some of them swear by it, and of
course there are many more Chrome or Chromium users theses days.
> The code I've added uses a small, local web service running in the
> Python Flask framework which accepts requests from the browser plugin
> and writes the recoll webcache files out to their target directory. I
> did it this way because I was unable to get the Chrome version of the
> downloads.download method used in the plugin to reliably set the
> filename of the downloaded file. Chrome has a
> downloads.onDeterminingFilename listener that any plugin can instantiate
> which can and will modify the filename used in all browser file
> downloads. I couldn't find a reliable method to prevent the listener
> defined in the "Aria2c Integration" plugin I have installed, for
> example, from changing the filenames of my recoll-we plugin download
> files. A secondary factor was that, while I like to use the downloads
> bar in the browser, I don't like having two recoll downloads show up
> there every time I visit a web page. Using a local web service as I did
> avoided these problems. On the other hand, adding a web service to this
> process adds yet another level of complexity. Fine for somebody like
> me, not so good for a user who expects it all to "just work."
Yes, having a separate process running does seem a bit over the top for
this. The script which moves the file to the Recoll queue could be adapted for
any workable naming scheme if you can work one up.
> I couldn't register on opensourceproject.eu so I couldn't fork JF'sThanks for that information. The Firefox web store lists opensourceprojects as the "Support site" for the plugin. That's why I went there. But I didn't use the code from that site. As I said above, I'm working with the code I unpacked from the v2.1 XPI file that I downloaded from the Fedora web store.
> recoll-we code there. Even tried VPNing to an EU IP address but I kept
> getting 500 errors no matter where I came from. So, I've put my version
> of the plugin on github, at https://github.com/dlk3/recoll-we-chrome.
> My mods are in the background.js and the new recoll-we-webservice.py
> scripts.
opensourceprojects.eu is dead, and the code there is quite a bit behind the
current code for the extension which is here:
https://framagit.org/medoc92/recoll-we
I'm not sure how far off is the code you started from open opensourceprojects,
this would be the first thing to check.
I'd delete the opensourceprojects repositories, but I can't even log in to the
site any more...
Cheers,
jf
