Hello, I'm sending two patches with an idea to solve this problem.
It's a proof of concept that I'm offering to develop and complete, although I have very little free time.
The first patch works with the latest dillo release (3.3.0) but also works with the current repository.
It implements changes in dillo, download.dpi, and the file and data DPIs as examples.
The second patch works with the latest gopher.dpi repository.
The main idea is that the DPIs that handle protocols save the URL and write the file themselves, coordinating with download.dpi and dillo.
To do this, they implement a new DPI command: `save_url`
d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", url, dl_dest);
Dillo initiates a download, sending it to download.dpi as before. If it's HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will send a `save_url` command to Dillo to coordinate. This allows Dillo to notify the user, verify the security of the change, etc.Currently, Dillo only checks if there's a DPI that handles the requested protocol.
(A new function (`a_Dpiapi_is_service_handled(server_str)`) queries `dpid` without executing the DPI. No code is modified in `dpid`. Modifying `dpid` or executing the DPI would allow querying the capabilities of the DPIs, but it doesn't seem necessary.)
- If a DPI is present, it sends the `save_url` command to the DPI that coordinates with `download.dpi` via a secondary channel so that downloads can continue even if all Dillo windows are closed.
- If the protocol isn't handled, it notifies download.dpi through the secondary channel (this reduces the amount of code).
The next step would be to implement `save_url` in other protocol DPIs.
A possible change to download.dpi once all is done is to leave download.dpi it as just a GUI for DPIs and extract the code to download HTTP to a DPI. (There's already ftp.dpi)
One last thing: can you recommend a simple Git manual?
Saludos
Diego.