edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [Edbrowse-dev] plugin commands
@ 2015-04-11 21:53 Karl Dahlke
  2015-04-12 14:24 ` Adam Thompson
  0 siblings, 1 reply; 2+ messages in thread
From: Karl Dahlke @ 2015-04-11 21:53 UTC (permalink / raw)
  To: Edbrowse-dev

Well I thought this mime content thing would be an easy weekend project,
but the mime stuff, like a lot of my stuff,
looks like it was slapped together without enough thought.
I need to do some redesign of mime plugins.

I'll focus on audio, obviously I have a vested interest in that world.
Say there is a web file that I have determined, by suffix or by content type,
to be mp3, and I have a mime description of what to do with mp3.
Good so far, but there are three possible scenarios,
and I'm starting to think I should allow for 3 different commands.
These are stream, local file, and in memory.
This is how it might look.

cmdstream = mpg123 -q -C
cmdlocal = mpg123 -q -C
cmdmem = mpg123 -q -

The stream command, if it is present and if that is the one edbrowse selects,
is invoked with the url.
mpg123 -q -C url
No need to download a possibly large audio file, and it starts playing right away.
Some of the key controls work, particularly pause and fast forward.
Others do not, such as rewind or randomly jump to points 1 through 10 in the file.
So you get some of the interactive benefits of an audio player, but not all.

The most flexible plugin command, if the downloaded audio file is not too large,
is the local command, wherein edbrowse would download
and save it somewhere in /tmp and then run
mpg123 -q -C /tmp/foobar.mp3
All the key commands are available, rewind, restart, forward, random access.

The third command downloads the mp3 file into memory and then pipes
it to the running program.
buffer | mpg123 -q -

This allows for *none* of the key commands, since standard in is busy
reading the mp3 samples.
The only thing you can do is abort with control c.

So these are the possible commands and I think I should allow for at least 2 of them,
stream and local, and maybe all three, in each mime descriptor.

Of course something like streaming audio would only have the stream command.
The others are not meaningful.

If a particular mime type offers multiple commands, how would edbrowse pick?
Should there be a master switch, a toggle command like
pgs pgl pgo
plugin streams plugin local plugins off?
Turning it off would only be used if you liked what you were hearing,
the lecture is really interesting, and you want to download it
like it's just a file.
Some real interesting things to think about here.

Karl Dahlke

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Edbrowse-dev] plugin commands
  2015-04-11 21:53 [Edbrowse-dev] plugin commands Karl Dahlke
@ 2015-04-12 14:24 ` Adam Thompson
  0 siblings, 0 replies; 2+ messages in thread
From: Adam Thompson @ 2015-04-12 14:24 UTC (permalink / raw)
  To: Karl Dahlke; +Cc: Edbrowse-dev

[-- Attachment #1: Type: text/plain, Size: 4406 bytes --]

On Sat, Apr 11, 2015 at 05:53:36PM -0400, Karl Dahlke wrote:
> Well I thought this mime content thing would be an easy weekend project,
> but the mime stuff, like a lot of my stuff,
> looks like it was slapped together without enough thought.
> I need to do some redesign of mime plugins.
> 
> I'll focus on audio, obviously I have a vested interest in that world.
> Say there is a web file that I have determined, by suffix or by content type,
> to be mp3, and I have a mime description of what to do with mp3.
> Good so far, but there are three possible scenarios,
> and I'm starting to think I should allow for 3 different commands.
> These are stream, local file, and in memory.
> This is how it might look.
> 
> cmdstream = mpg123 -q -C
> cmdlocal = mpg123 -q -C
> cmdmem = mpg123 -q -
> 
> The stream command, if it is present and if that is the one edbrowse selects,
> is invoked with the url.
> mpg123 -q -C url
> No need to download a possibly large audio file, and it starts playing right away.
> Some of the key controls work, particularly pause and fast forward.
> Others do not, such as rewind or randomly jump to points 1 through 10 in the file.
> So you get some of the interactive benefits of an audio player, but not all.

One question about this:
Are we using a head request for http to determine this?
I ask as in some situations I can think of,
re-invoking the player with the URL once downloading has began may break things
in unexpected ways. I suspect the same may be true of head requests,
but at least a sane setup should handle that correctly.

> The most flexible plugin command, if the downloaded audio file is not too large,
> is the local command, wherein edbrowse would download
> and save it somewhere in /tmp and then run
> mpg123 -q -C /tmp/foobar.mp3
> All the key commands are available, rewind, restart, forward, random access.

Agreed, plus you avoid network-related buffering this way.

> The third command downloads the mp3 file into memory and then pipes
> it to the running program.
> buffer | mpg123 -q -
> 
> This allows for *none* of the key commands, since standard in is busy
> reading the mp3 samples.
> The only thing you can do is abort with control c.

Does this download and send in chunks or download the entire thing and then
send it to stdin of the player? If we could have a command which simply
downloaded and passed the data straight to the player then that'd handle all
audio distribution weirdness I can think of (that uses http that is).
For example the strange js -> cookie -> cdn -> session specific URL setups that
seem to be appearing (particularly with internet radio)
would perhaps break with any of the above setups,
but downloading and handing off the data as I describe (and may be as
implemented) would work correctly with these systems.

> So these are the possible commands and I think I should allow for at least 2 of them,
> stream and local, and maybe all three, in each mime descriptor.

Agreed, with a possible use of fifos as well to provide for circumstances where
you want to pipe the data from the browser but still would like your media 
controls.

> Of course something like streaming audio would only have the stream command.
> The others are not meaningful.

Again, sounds sensible. I'd also be in favour of some sort of protocol set up
which would hand off URLs to external programs,
for example rtsp may be handed to mplayer for playing.
This would be sort of independant from this discussion,
but the error message I get for unknown protocols references my mime type config.
> If a particular mime type offers multiple commands, how would edbrowse pick?
> Should there be a master switch, a toggle command like
> pgs pgl pgo
> plugin streams plugin local plugins off?
> Turning it off would only be used if you liked what you were hearing,
> the lecture is really interesting, and you want to download it
> like it's just a file.
> Some real interesting things to think about here.

Liking the toggle, but I'd also like a pga option for plugins ask,
which presents me with a prompt. I'd use that in cases where I wasn't exactly
sure what the website was going to do,
since otherwise I may inadvertantly stream something when I wanted to download
it, or try and download a live stream which'd be... unfortunate.

Cheers,
Adam.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-04-12 14:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-11 21:53 [Edbrowse-dev] plugin commands Karl Dahlke
2015-04-12 14:24 ` 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).