Re: [Edbrowse-dev] Messages to and from edbrowse-curl

[Adam Thompson <arthompson1990@gmail.com>]

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

A few thoughts:
On Wed, Dec 30, 2015 at 05:00:44PM -0500, Karl Dahlke wrote:
> * Update a runtime parameter.
> These are the commands like vs sr fmp fma hr that influence internet fetches.
> We changed the variable in edbrowse,
> this is a message to change the same variable in edbrowse-curl.
> Response:ack   - if a response is even required.
> There's some question of whether these changes are system wide,
> which would be the easiest to implement.
> type vs in any running instance of edbrowse and we are not verifying ssl for any
> of the running edbrowse programs, because edbrowse-curl isn't doing that, or,
> edbrowse-curl maintains instances of these variables for each connected edbrowse.
> I really don't know the answer to this and don't have a strong opinion on it.

I'm thinking probably that each user would need their own edbrowse-curl,
and that within each edbrowse-curl we'd keep track of the individual instances
of edbrowse connected to it. This handles a bunch of otherwise potentially odd 
corner cases.

> * Fetch this url, generic.
> curl does most of what is in http today, store cookies,
> follow 301 302 redirections if that feature is enabled,
> until it reaches data, or some other condition.
> Responses:
> - The data, coming over a stream or in a temp file or whatever makes sense,
> and perhaps the headers as well.
> - A request for user name and password, http code 401.
> edbrowse-curl shouldn't be doing I/O, edbrowse gets the username
> password and sends it back to edbrowse-curl.
> - Debugging information if db4, the curl traffic sent and received.
> This we just print when we get it and wait for the next response.
> - Various urls that the browser is redirected to, if db2.
> Again, this is debug information that we just print.
> - The new url, the actual location of the page after redirection.
> This becomes the "filename" of the page, and the base for relative url resolution.
> - url looks like a streaming mime type.
> We usually know this from protocol or suffix, but maybe that wasn't clear
> until content-type was compared against your plugins.
> - Progress dots, one per megabyte. Again we just print these.

No, I think we just download the data,
may be have a status message and then it's up to edbrowse what it does.
> - Looks like a file you'll want to download, supply a file name or x to abort
> or space to read in memory as usual.

Again, I'd just download the data, if we want to pull it into memory then we
can potentially do that, but mean while the data download carries on.
I'm thinking that makes more sense because in the case of small files the IO
penalty is probably not that high, and in the case of large files we probably
don't want to load them into memory anyway.
That also gives us a way to implement a sort of page cache in the future if we 
want to.

> * Fetch this url and download to a file.
> This is followup from the previous response, if you requested download to disk.
> We should sent the final url, not the initial url.
> Indicate foreground or background.
> It's possible that edbrowse-curl doesn't care which,
> just a matter of whether edbrowse waits for this to finish or moves on,
> but it does matter because edbrowse-curl only sends the progress dots
> if download is in the foreground.
> Or maybe just an independent parameter for dots or no dots.
> They aren't printed when fetching javascript, for instance.

See above for thoughts on the dots. At the end of the day, that's aUI decision, i.e.
on my internet connection I'd quite like to switch them off entirely tbh
because, depending on the server,downloads happen either so fast I can't count the dots or so
slowly that having a random dot appearing is not very useful when I don't know
the actual file size.
Try counting how far through a 200 meg download you are in dot form,
may be your personal speech adapter does that but on a braille display it's
just a huge string of dots and speakup also doesn't do that as far as I know.
What I'd actually like is a way to find out the file size (usually from the
content-length header) and the actual amount (to the byte preferably)
that's actually been downloaded so I can see how long I have to wait.

> * cookie name=value
> This is the result of <meta http-equiv=set-cookie> or by javascript
> document.cookie = "foo=bar";
> Response:ack   - if a response is even required.
> 
> * Get cookies for this url.
> These are used to populate document.cookie when javascript starts.

That makes sense.

Cheers,
Adam.

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