CAPI ignores download requests when not in cache or handled by the downloads DPI.

[Jeremy Henty]

I wondered why "Save link as" silently failed on some of my local web
pages if I had not already visited the link. It turns out they were
"file:///" links and "Save link as" sends a download request which the
CAPI silently ignores if the URL is not cached and is not handled by
the downloads DPI.

I added a MSG_WARN to log this but haven't changed any behaviour. I
still found it surprising and was wondering if it could be improved?

Regards,

Jeremy Henty

[p***@public.gmane.org]

Post by Jeremy Henty
I wondered why "Save link as" silently failed on some of my local web
pages if I had not already visited the link. It turns out they were
"file:///" links and "Save link as" sends a download request which the
CAPI silently ignores if the URL is not cached and is not handled by
the downloads DPI.
I added a MSG_WARN to log this but haven't changed any behaviour. I
still found it surprising and was wondering if it could be improved?

I think the right way to fix it is to redesign downloads DPI so that
it doesn't duplicate downloading code. I already said that in Gopher
DPI therad.

Instead, Dillo could download files and pass them to downloads DPI.
Downloads DPI then shows progress and saves files. As I understand, the
idea is to have one window for all downloads across many copies of Dillo
where progress can be shown and requests to cancel them can be passed to
the right copy of Dillo.

In the current state only http, https and ftp links are passed to DPI,
you can see it in a_Cache_download_enabled.

[Jeremy Henty]

I wondered why "Save link as" silently failed on some of my local
web pages if I had not already visited the link. It turns out
they were "file:///" links and "Save link as" sends a download
request which the CAPI silently ignores if the URL is not cached
and is not handled by the downloads DPI.
[...]

[...]
Instead, Dillo could download files and pass them to downloads DPI.
Downloads DPI then shows progress and saves files. As I understand,
the idea is to have one window for all downloads across many copies
of Dillo where progress can be shown and requests to cancel them can
be passed to the right copy of Dillo.

I wonder what is the real benefit of a separate downloads DPI. Is it
actually useful to have one downloads window for all Dillo processes?
The downloads DPI is rather different from all the rest: it is the
only one that links to FLTK and it doesn't send HTML back to Dillo.
Do we really benefit from putting downloading in a separate process?

Regards,

Jeremy Henty

[corvid]

Post by Jeremy Henty
I wonder what is the real benefit of a separate downloads DPI. Is it
actually useful to have one downloads window for all Dillo processes?
The downloads DPI is rather different from all the rest: it is the
only one that links to FLTK and it doesn't send HTML back to Dillo.
Do we really benefit from putting downloading in a separate process?

I think I would prefer to save things using dillo directly rather than
having dillo get something, figure out that it can't display it,
abort the connection, have this other process start over again in
another window... (I tend to use wget by hand in order to avoid all
of that.)

[p***@public.gmane.org]

Post by Jeremy Henty

I wondered why "Save link as" silently failed on some of my local
web pages if I had not already visited the link. It turns out
they were "file:///" links and "Save link as" sends a download
request which the CAPI silently ignores if the URL is not cached
and is not handled by the downloads DPI.
[...]

[...]
Instead, Dillo could download files and pass them to downloads DPI.
Downloads DPI then shows progress and saves files. As I understand,
the idea is to have one window for all downloads across many copies
of Dillo where progress can be shown and requests to cancel them can
be passed to the right copy of Dillo.

I wonder what is the real benefit of a separate downloads DPI. Is it
actually useful to have one downloads window for all Dillo processes?

I think downloading should not be done by downloads DPI: this way it
have to support all the protocols Dillo and its plugins support. But
tracking of downloads can be left there so we don't see the difference
between two dillo processes and two dillo windows.

Post by Jeremy Henty
The downloads DPI is rather different from all the rest: it is the
only one that links to FLTK and it doesn't send HTML back to Dillo.
Do we really benefit from putting downloading in a separate process?

Cookies DPI doesn't send HTML too. Downloads and cookies are server
DPIs, they are used to share resources between processes.

[Jorge Arellano Cid]

Post by Jeremy Henty

I wondered why "Save link as" silently failed on some of my local
web pages if I had not already visited the link. It turns out
they were "file:///" links and "Save link as" sends a download
request which the CAPI silently ignores if the URL is not cached
and is not handled by the downloads DPI.

Capi shows a warning in the command line...

Anyway, the request (a local file copy) is ignored, but can
be implemented easily in the dpi for orthogonality.

Post by Jeremy Henty
[...]
I wonder what is the real benefit of a separate downloads DPI. Is it
actually useful to have one downloads window for all Dillo processes?

You'll find the rationale in doc/Dpid.txt