From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 17E5477EF7 for ; Fri, 1 Jan 2016 12:18:32 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id b14so114762411wmb.1 for ; Fri, 01 Jan 2016 12:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=jsxFJ5xpRKOs0iA4ll0f2iYqJVYo5dApc7kyTY2oljw=; b=tEpEPo2Y9mKkiywj9VG5StOuZ39m+qF8wQ7kYrJKZHPpzXF4yxcXg3coYbaeZr80Rm mK8O79g1u08PMYg+aI8fXCydriC8Zsaa8aXljg1ZTKatvRjuR4S0jUNzSghvsza13RJs PFtkudXdF0BcJgrIacJh+RjvQb91oajnUTWNA25ZwopraLy2P1wirqJoDkT0fENZuCqt IuzJch6naec+lDbjJOCqV/BZo0UVIOmoIXihSoRzXqW0Q8MlX51gVHwNFec+Lu3uQb/S AafQ/zKS/8L1bQskSEMQCYMvaj5Y0QRkgava3vV1++FY+Bzwfv2rWDlBHNksmy10XgA5 oQKg== X-Received: by 10.194.174.229 with SMTP id bv5mr97606350wjc.29.1451679542275; Fri, 01 Jan 2016 12:19:02 -0800 (PST) Received: from 122oven.adamthompson.me.uk (c.2.2.f.4.7.e.f.f.f.d.1.4.2.2.0.2.4.0.9.2.4.1.1.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:1142:9042:224:1dff:fe74:f22c]) by smtp.gmail.com with ESMTPSA id jm4sm74532098wjb.7.2016.01.01.12.19.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2016 12:19:01 -0800 (PST) Date: Fri, 1 Jan 2016 20:18:59 +0000 From: Adam Thompson To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20160101201859.GG12402@122oven.adamthompson.me.uk> References: <20151130170044.eklhad@comcast.net> <20160101182449.GB12402@122oven.adamthompson.me.uk> <20160001140534.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4eRLI4hEmsdu6Npr" Content-Disposition: inline In-Reply-To: <20160001140534.eklhad@comcast.net> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [Edbrowse-dev] Messages to and from edbrowse-curl X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jan 2016 20:18:32 -0000 --4eRLI4hEmsdu6Npr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 01, 2016 at 02:05:34PM -0500, Karl Dahlke wrote: > > Yeah that makes sense actually, but what do we do with the download > > in the meantime? > > I'm not sure if we should just pause waiting or not. >=20 > No I don't think that's good. > Servers will time out etc. > Nor do I think we should start writing to a temp file and move data aroun= d later. I agree none of these solutions are ideal but I'm not sure about the correc= t=20 solution here. > I can tell you what we do today and hope that helps. > I analyze the headers as they come in and compare them > against standards and plugins etc. > If it is not text, and not something you know you want to download to play > as a plugin, say usually some kind of binary, > then I stop the download after the headers, > as though it were a HEAD call. > There's a curl command to stop the download gracefully. > Once I know where to send the data, I restart the call. My issue here is with any fancy redirects we may encounter. Theoretically they should work but I can think of cases where this may break when we try and restart the download. > I get the headers and the data and into the file it goes > and it all works without trouble. Agreed. > I imagine edbrowse-curl would analyze the headers as we do now, > and if a potential download, it sends the message back to edbrowse and st= ops. > Then edbrowse sends message back restarting the download > into the designated file, > thus the different messages: fetch generic and fetch into a named file. I'd rather not do the restart if at all possible. I'd rather download and move data, that's not too bad. May be we have a maximum grace time after which we stop, but I'd rather not just stop the download. Or work out how to do either a head call for http or an ftp call (I'm fairly sure I've seen one) since any server *should* support that. > Sure, I'll work on some different progress options, > including quiet, no progress indicators at all, > just the file size when done. The more I think about it, the more i like the 7/235 megabytes option print= ed at a fixed rate. If we can also get status into the background download monitoring as well that'd be great. > I'm happy to work on little features in parallel, > and there seems to be plenty of them. Brilliant, thanks. Cheers, Adam. PS: I can't remember but I know we have a plugins off and plugins on, but do we have a plugins ask as well? There are times when I'd like to choose whether to use a plugin at the poin= t of download. --4eRLI4hEmsdu6Npr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWht8zAAoJELZ22lNQBzHOGMYIAM7n4vvj0mhjL+AaJdVdgvpf h2YerGlRVpCKWev6/S7BHwKIdGl0exntg2krq+q1MxKXESn9N2tZoNFGRCkLkT2+ U9T/Mj0bY5dYjUNCCZzMRaUkR7+7ms025TO7u77ASPzCfZUeaNZOFtavR4hPHuhf oA74KzMZuLhOM8xJXnaIC6YI5SkYVAXV5ykvHiSPbKWqk3fmNwPUa3hESEct0JE1 XQHf/ijF++S7RTW+ZYImWws4vqDMI9MdAa5SOERlH4pqvgZneEZaBuoUfkZ+FFFB +6Q1z75zv6TRWUa+nX2PDdZAENvMUHWKRiTOibFlQ/FgI2aCEE1RT/X+17vBOVQ= =UVxy -----END PGP SIGNATURE----- --4eRLI4hEmsdu6Npr--