* [Edbrowse-dev] Plugin Converters @ 2015-04-15 6:20 Karl Dahlke 2015-04-15 7:23 ` Adam Thompson 0 siblings, 1 reply; 4+ messages in thread From: Karl Dahlke @ 2015-04-15 6:20 UTC (permalink / raw) To: Edbrowse-dev Plugins that convert files into text or html are now employed by the browse command. In other words, the call to /usr/bin/pdftohtml is no longer hard coded. Here again is my pdf block. plugin { type = pdf desc = pdf file suffix = pdf content = application/pdf program = pdftohtml -i -noframes %i %o >/dev/null 2>&1 # outtype makes it a converter, h for html or t for text outtype = H } This means you are free to try other pdf converters if you wish, or rich text or word docs or open docs etc. There is pdf to text that I haven't tried, because I rather like keeping the hyperlinks. Karl Dahlke ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Edbrowse-dev] Plugin Converters 2015-04-15 6:20 [Edbrowse-dev] Plugin Converters Karl Dahlke @ 2015-04-15 7:23 ` Adam Thompson 2015-04-15 14:24 ` Karl Dahlke 0 siblings, 1 reply; 4+ messages in thread From: Adam Thompson @ 2015-04-15 7:23 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 1183 bytes --] On Wed, Apr 15, 2015 at 02:20:22AM -0400, Karl Dahlke wrote: > Plugins that convert files into text or html are now employed by the browse command. > In other words, the call to /usr/bin/pdftohtml is no longer hard coded. > Here again is my pdf block. > > plugin { > type = pdf > desc = pdf file > suffix = pdf > content = application/pdf > program = pdftohtml -i -noframes %i %o >/dev/null 2>&1 > # outtype makes it a converter, h for html or t for text > outtype = H > } Cool. Does the outtype work with protocol handlers as well, and would it be possible to have a generic outtype? I'm thinking of trying to get the following to work: plugin { type=scp url protocol=scp program=curl -s -o %o outtype=buffer } Or something like that. The idea of the above plugin block is that curl is used to download the file over scp then edbrowse loads it into the buffer. Of course I know the same can be achieved by using the scp command (or some script) and then loading the download into the buffer, but I'm thinking that for some protocols it'd be nice to be able to get edbrowse to automatically load (and possibly browse) the output. Cheers, Adam. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Edbrowse-dev] Plugin Converters 2015-04-15 7:23 ` Adam Thompson @ 2015-04-15 14:24 ` Karl Dahlke 2015-04-16 19:29 ` Adam Thompson 0 siblings, 1 reply; 4+ messages in thread From: Karl Dahlke @ 2015-04-15 14:24 UTC (permalink / raw) To: Edbrowse-dev > Cool. Does the outtype work with protocol handlers as well, No, but I don't think that would be hard to do. > 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. Karl Dahlke ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Edbrowse-dev] Plugin Converters 2015-04-15 14:24 ` Karl Dahlke @ 2015-04-16 19:29 ` Adam Thompson 0 siblings, 0 replies; 4+ messages in thread From: Adam Thompson @ 2015-04-16 19:29 UTC (permalink / raw) To: Karl Dahlke; +Cc: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 2688 bytes --] 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. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-16 19:31 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-15 6:20 [Edbrowse-dev] Plugin Converters Karl Dahlke 2015-04-15 7:23 ` Adam Thompson 2015-04-15 14:24 ` Karl Dahlke 2015-04-16 19:29 ` Adam Thompson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).