[Edbrowse-dev] various

[Edbrowse-dev] various

[Karl Dahlke]

> Why don't you do a head request before the get?

This won't help for ftp, where I really have to see the first data block
before I can ask the user and establish the download.
I could just abort the download and start it again into the file.  Yuck.
Or just not put it in the background, since as I say,
I don't think that's a big plus.
I've got 11 other consoles to play with.
Personally I'd rather keep it foreground and see the progress dots.
Playing with it a bit, I really miss the dots.
We don't have to do everything the way other browsers do.
I guess I would vote to scrap the background part.
The real plus here is sending data straight to disk,
especially when files are significantly larger than ram.

> I pushed a change to allow expansion of env variables etc for non-existant
> file names when writing or setting the file name.

Hmmm. That's not how it worked before, but I imagine it's how
most people would want it to work.
Maybe I'm odd but I never ran into this situation
in all the years of using edbrowse.

> I'd say delete it now, since it appears to work

Done.

> I've pushed a small change to enable history in readline input mode.

I don't know anything about readline, so can't comment.


Karl Dahlke

Re: [Edbrowse-dev] various

[Adam Thompson]

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

On Tue, Dec 30, 2014 at 10:38:20AM -0500, Karl Dahlke wrote:
> > Why don't you do a head request before the get?
> 
> This won't help for ftp, where I really have to see the first data block
> before I can ask the user and establish the download.
> I could just abort the download and start it again into the file.  Yuck.
> Or just not put it in the background, since as I say,
> I don't think that's a big plus.
> I've got 11 other consoles to play with.
> Personally I'd rather keep it foreground and see the progress dots.
> Playing with it a bit, I really miss the dots.
> We don't have to do everything the way other browsers do.
> I guess I would vote to scrap the background part.
> The real plus here is sending data straight to disk,
> especially when files are significantly larger than ram.

I guess it depends on your usage pattern.
I tend to have a browser open and use the multi-buffer capability to simulate
tabs etc, and having one buffer block the entire browser whilst a large file
downloads kind of prevents this. I'm not sure how to handle ftp,
but I suspect that most of the time you'd want to download from ftp to disk
rather than into memory, or may be that's just how I tend to use ftp.

I think the problem is more of designing the feature so that it works as
expected, allowing both downloading into the background and with
progress dots, both straight to disk.
That's going to be a slightly harder problem,
but I agree that download to disk is more important.

> > I pushed a change to allow expansion of env variables etc for non-existant
> > file names when writing or setting the file name.
> 
> Hmmm. That's not how it worked before, but I imagine it's how
> most people would want it to work.
> Maybe I'm odd but I never ran into this situation
> in all the years of using edbrowse.

Yeah, I guess I'm just used to how the shell works with these things.

> > I'd say delete it now, since it appears to work
> 
> Done.

Ok, thanks.

> > I've pushed a small change to enable history in readline input mode.
> 
> I don't know anything about readline, so can't comment.

Ok, it seems to work as expected.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]