[Edbrowse-dev] Plugin Converters

[Edbrowse-dev] Plugin Converters

[Karl Dahlke]

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

Re: [Edbrowse-dev] Plugin Converters

[Adam Thompson]

[-- 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 --]

[Edbrowse-dev] Plugin Converters

[Karl Dahlke]

> 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

Re: [Edbrowse-dev] Plugin Converters

[Adam Thompson]

[-- 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 --]