From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 6CC977ADCF for ; Thu, 16 Apr 2015 12:31:12 -0700 (PDT) Received: by wgso17 with SMTP id o17so91946131wgs.1 for ; Thu, 16 Apr 2015 12:30:08 -0700 (PDT) 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=0qMszYxR6Drw03GOAMhWSCrAgzqRoqqXic0Y2kIgunI=; b=Yqat/YzhUtqEdaAtQGBwoRyie0dlhEb7IthOugHVLBjyyPkqri9cWldmj/O032rXV4 Mm108Fx2BSLZB8FJ55tyya7WdT3J3jYT4XJI4dl3hQAlbeImDTQk6OCBllMWXinx04o2 MEeui9R2bxHcyqDY/t8Kw1tGKRkAzCUoV5FmIkMGYCifcQ/UHrUEHvMwaMMfh4IabAVY ae29oTJOJbYe0FmgFbxVNXL6hDxXt85rQ8ouBVszQ+z2kJjFZrAylFOb1GwUsEnnzYWI UDW+Rhfg3U4Q4GU3/NJX8A+sRaQLv+iqbHKAeQfIq1/b2cG+tctN8vHbUIlv+co7y6Sb WUnQ== X-Received: by 10.194.77.7 with SMTP id o7mr62197252wjw.95.1429212608673; Thu, 16 Apr 2015 12:30:08 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id eu3sm11622514wjb.16.2015.04.16.12.30.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Apr 2015 12:30:07 -0700 (PDT) Date: Thu, 16 Apr 2015 20:29:59 +0100 From: Adam Thompson To: Karl Dahlke Message-ID: <20150416192959.GA5949@toaster.adamthompson.me.uk> References: <20150315022022.eklhad@comcast.net> <20150415072306.GK9150@toaster.adamthompson.me.uk> <20150315102414.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20150315102414.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Plugin Converters 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: Thu, 16 Apr 2015 19:31:13 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 15, 2015 at 10:24:14AM -0400, Karl Dahlke wrote: > > Cool. Does the outtype work with protocol handlers as well, >=20 > No, but I don't think that would be hard to do. That'd be useful I think. Of course this example is somewhat contrived, but I can foresee needing to add more complex commands which output either = html or text formatted output in order to handle more exotic protocols. This feature would give us a very flexible extension mechanism. Bonus points if we could do something like allow the plugin to provide mime type info back to the browser, i.e. a custom protocol handler may either download video, audio or html. Edbrowse could then decide how to handle the downloaded content. This would be a bit more involved, but we could possibly use http headers f= orthis, i.e. the plugin generates a representative set of http headers and passes this t= o edbrowse. Of course the API would need more work (and probably http headers aren't the right solution), but I think the idea's sound, and would give us a more fully integrated plugin mechanism. Given the increasingly large amount of browser extensions, this would be useful, though I accept that it's probably not likely to happ= en=20 quickly. Actually, thinking even more about this, I wonder if we shouldn't have two = types of protocol handlers: Streaming and external viewers. Streaming protocol handlers would be expected to provide their output to Edbrowse as a raw stream which could then run through the normal download machinary (with possible mime type indication). External viewers would just get handed the URL and display the output to the user, with the user returning to edbrowse once they've finished. This is what we've currently got, and works well for most situations. > > Example of scp: protocol fetching a file into the buffer. >=20 > But this raises the question, shouldn't we handle this natively? > Any protocol that means "fetch this file into the buffer > so I can manage it" is probably going to be accomplished > by invoking a curl command, > which means we could do the same thing through the curl library. > And we wouldn't be fetching the file into a temp file, > then into the buffer, then, most likely, saving it to a file on disk > where you really want it; > we would use all the existing machinery such as asking you if you want to > download it to disk directly, perhaps in the background. > scp: is very likely for downloading files, not casual browsing. > We already handle ftp sftp ftps tftp in this manner, > I would think I should just add scp to the list. In this case, yes we should just add scp to the list. Cheers, Adam. --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVMA23AAoJELZ22lNQBzHOS1AH/Rxhh6MXTDOVncwHXkK3Fuhg K00qEMMyV3RTCjmcsVMxP2PRIT9Dfl0eiHkioXsNKkzKN7QUJJELyIA3XlqcdlNI FOvssgr6wws7fGlxGeoaFNzsPDHKSeT7N5md0SfTF4PmgQLptRvV70fpCIx8zX3v TXdllSgTghu2L2CepXRjTS4SAsgS5nvw6EzsWRBbwOue7ca937VTqWLfiOAHYx1s yZKjuWwJrcmZC81HkQh85hjUy4vlNd6zlMly1j8SZ/PywTD2D95kNNv6UlmWy5AT eKATNbX3bfQZqxZCtNRGG536g6I5bWVCkZnpJk6018/UjkaG/Oj1ZiSGryjf6fs= =VPva -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI--