From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 052BE786FA for ; Sat, 3 Jan 2015 07:36:25 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-04v.sys.comcast.net with comcast id bTZC1p0062S2Q5R01Ta3iT; Sat, 03 Jan 2015 15:34:03 +0000 Received: from eklhad ([IPv6:2601:4:5380:4ee:219:21ff:feb9:ba8d]) by resomta-ch2-16v.sys.comcast.net with comcast id bTa21p00508MP5701Ta2N3; Sat, 03 Jan 2015 15:34:02 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.2 Date: Sat, 03 Jan 2015 10:34:02 -0500 Message-ID: <20150003103402.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420299243; bh=nfbDQp0E33AILU0t7Iw5MeWBUmNmo4qzmukQgdWPTqg=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=VEj/kx+1W8XKqRbDkblWJmGrQ3WRj8qrIcnMdDb/X7TIIKcKA/ysCEbukvak4Fiiq v6xx1crccJhkKGKDHT9L1gXCWrb1KtHBkmFexpQusDE1bNT7kontjuXNhWTyofdmYa CUaop7sE+NnObiUTfH/h3d9k5v/ljXD+H2EcAzWpwKDJ3iVch0DqYugRQcgkj8lQ04 r6Ksyu3uNwfhLj+g0+x5F8wPW5tO0rDqOJSSXGT7jlXPCSWLFoTEbVTb2RyKoEkGhA KdE5SoysTcA4FUp9QhckRqybcWOCeQH8SrD4KvgM52IqoywXJswu6lJeO3MIY5MtNX yDm8AKeiDKFfg== Subject: [Edbrowse-dev] curl things X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2015 15:36:26 -0000 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