[Edbrowse-dev] curl things

[Karl Dahlke <eklhad@comcast.net>]

Welcome back from wherever, and hope you had a grand time.
We have missed your thoughts and advice and wisdom,
but have pressed on anyways.
Your git pull will have a lot of fast forwarding to do.
Read through all our emails and you'll see where we are.
Do make comments on what we have done so far.

> I have plenty of time, and I'm happy to work on this.

That's great news.

As you see, download in the background works for http and ftp,
but not their secure versions,
due to some kind of curl interruptus.
This is the failure case.
https://archive.torproject.org/amnesia.boum.org/tails/stable/tails-i386-1.2.2/tails-i386-1.2.2.iso
Not sure the best plan - maybe (the easy way) I can just return
something different from callback and it will do what I want,
or I can just close the socket in parent before returning -1,
then whatever curl does will not disrupt the server
and what it is doing with the child.
Or maybe the roles of parent and child must switch, if ssl
uses the process id somewhere and must march along.
Uglier cases are to abort and restart the secure download,
or forget about doing it in the background and just download to disk,
which is valuable in itself.
Or just put plain downloads in background, as almost all of them are plain,
and keep secure in foreground, but that could be confusing.
IDK

The most important step in imap might be a clean command line
interface to same, that is not far different from the one in fetchmail.
Don't know a lot about imap, or curl's support thereof,
but would probably like it if it was there.

My next project, which is not a major redisign,
but more like filling in some holes,
is to fix tag.innerHTML = "foobar", in js.
This never really worked properly, never.
It injects html into the page, after it is parsed,
but my parsing software in html.c was built to be a one time thing,
so there is some work to do here.
I use to get around this by dumping the injected html into another buffer
and rendering it there, but that is ugly.
It belongs where it belongs, under the specified tag
on the current page.
And for calls to document.write() after browse, I use to do the same thing,
dump the html somewhere else and parse it in a separate window.
This is illustrated by line 3 in browsed jsrt, the timer, fire it and
watch what it does, ugly.
It should just append that (rendered) html to the current buffer.
Both issues are related, and I am making a series of small foundational
changes that will let me approach this one.

Karl Dahlke