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

On Tue, Jan 01, 2013 at 10:30:04PM +0000, Jeremy Henty wrote:
> 
> [email protected] wrote:
> 
> > On Sun, Dec 30, 2012 at 05:23:18PM +0000, Jeremy Henty wrote:
> > > 
> > > 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.

> 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.