On Wed, Apr 15, 2015 at 10:24:14AM -0400, Karl Dahlke wrote: > > Cool. Does the outtype work with protocol handlers as well, > > 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 forthis, i.e. the plugin generates a representative set of http headers and passes this to 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 happen 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. > > 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.
signature.asc
Description: Digital signature
_______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
