From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eklhad@comcast.net>
Received: from resqmta-ch2-09v.sys.comcast.net
 (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41])
 by hurricane.the-brannons.com (Postfix) with ESMTPS id 901227ACAF
 for <edbrowse-dev@lists.the-brannons.com>;
 Mon, 13 Apr 2015 09:36:01 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115])
 by resqmta-ch2-09v.sys.comcast.net with comcast
 id FUZQ1q0032VvR6D01Ub3K6; Mon, 13 Apr 2015 16:35:03 +0000
Received: from eklhad ([IPv6:2601:4:5380:4ee:21e:4fff:fec2:a0f1])
 by resomta-ch2-19v.sys.comcast.net with comcast
 id FUb21q00B5LMg2101Ub2ry; Mon, 13 Apr 2015 16:35:02 +0000
To: Edbrowse-dev@lists.the-brannons.com
From: Karl Dahlke <eklhad@comcast.net>
Reply-to: Karl Dahlke <eklhad@comcast.net>
User-Agent: edbrowse/3.5.3+
Date: Mon, 13 Apr 2015 12:35:02 -0400
Message-ID: <20150313123502.eklhad@comcast.net>
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net;
 s=q20140121; t=1428942903;
 bh=cPw9m+0XaUV+saRzh/13EUnVj9kiZP4v2DmCmie4+VU=;
 h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID:
 Mime-Version:Content-Type;
 b=dioP3kfsb9DCsqKT4iJdViXhQbweGnwT2rokzdOKlQN1kZPXVNVBLiX/hZWk3QrI6
 W1XAtncjOOfORDXd6z8/0upKfU2ZRKON6/mtHX48L2yu5YWJrA1Y+BOIDDGSEan6jZ
 iNT4l84wVPg3GyX/RhEADoPcGpPfD1i30/gRv9+qiLD+PKRzkH8NJy8Q5ov/oFb/pE
 fqVWuHjIzOWpHZ9WkjqLJRShoYiAWXZ3Jubuh3ClCJgoD/YmZmAwPaGJ/NJF6mT/c7
 uDv5gF4bzGy0QJ9cpTTnRIKFi6uP1NufaV0w1HZ18KvYEL5Sj5hxlVynYAFlHvdCEd
 M3DvhIN4jciUA==
Subject: [Edbrowse-dev] Play Commands
X-BeenThere: edbrowse-dev@lists.the-brannons.com
X-Mailman-Version: 2.1.18-1
Precedence: list
List-Id: Edbrowse Development List <edbrowse-dev.lists.the-brannons.com>
List-Unsubscribe: <http://lists.the-brannons.com/mailman/options/edbrowse-dev>, 
 <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=unsubscribe>
List-Archive: <http://lists.the-brannons.com/mailman/private/edbrowse-dev/>
List-Post: <mailto:edbrowse-dev@lists.the-brannons.com>
List-Help: <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=help>
List-Subscribe: <http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev>, 
 <mailto:edbrowse-dev-request@lists.the-brannons.com?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2015 16:36:02 -0000

New and/or modified play commands are described here, as of the latest push.
These are not yet documented.
I'm waiting for the interface to settle down a bit
before I muck with the users guide.

Here are the mimes from my config.
A new syntax in the command is %i for the input file, and %o
for the output file, the latter not yet implemented.
A temp output file might be employed when calling a pdf converter
or rich text converter or some such.
Which brings up the point that there are really two types of plugins here,
though they both look similar in syntax.
One "plays" a file or buffer for your enjoyment,
the other renders the buffer as part of the browse command.
mpg123 is the former, pdf to html is the latter.
Anyways, here's what I have, with the new %i syntax.

mime {
type = audio/basic
desc = audio file in a wave format
suffix = wav,voc,au,ogg
content = audio/x-wav
program = play -q %i
}

mime {
type = audio/mp3
desc = audio file in mp3 format
suffix = mp3
content = audio/mpeg
program = mpg123 -q -C %i
}

mime {
type = <audio/x-pn-realaudio
desc = streaming audio
protocol = rtsp,pnm,sdp
suffix = rm,ra,ram,pls
content = audio/x-scpls
program = /usr/bin/mplayer -quiet %i
}

#  this one doesn't work yet
mime {
type = pdf
desc = pdf file
suffix = pdf
content = application/pdf
program = pdftohtml -i -noframes %i %o >/dev/null 2>&1
#  This plugin generates meaningful output, in the form of html
outtype = H
}

If you have edited, or for some reason find yourself in a music file,
you can play it with the pb command as before.
Use pb.xxx if the filename does not contain the proper suffix, as before.
However, the command now creates a temp file and plays the music using that file.
The interface is just so much better for players
if you're playing a file, then piping data into standard in.
So many more features you can use to back up and replay and seek and so on.
It's well worth it, and not as costly as you might think,
thanks to some of the following features.

In directory mode, pb use to just give an error.
You can't play a directory!
But now it tries to play the file you are currently on.
No need to read it into a buffer (the first copy)
then copy it into /tmp (the second copy), just play it in place.
Try editing a directory full of songs or books or whatever
and just find the one you want and type pb.
It's kinda cool.
Again if the filename doesn't have a proper suffix you can provide your own
like pb.mp3

Sure, you could do the same thing with a simple edbrowse function.
#play the current line
function:pl {
!mpg123 -q -C '.
}
Then type <pl on anything you want to play.
That works great if all the files are mp3.
But what if some are wav or voc or ogg etc?
What if they are different audio formats?
The pb command uses your mime types and does the right thing.

Now turn to the web.
If you run into a web page that is actually an audio file,
it simply plays.
That's what happens in other browsers.
Chrome doesn't descend into the file and show it as binary and ask you to
figure out its audio type and issue the proper command to play it
and when you're done playing remember to back up
else you will be reading the contents of the binary bile which will probably screw up your terminal
and then you have to exit edbrowse and /usr/bin/reset the tty and jesus christ!
No, chrome just plays the file, and now that's what I do.
When it is done playing it says ok, so you know it's done and not just
playing a spell of silence.
You are on the line you were on before.
Type g to go again, if you want to hear it again.
This will naturally cause you to ask two questions.

1. What if I really did want to download that audio?

On windows there is a way, right click and save,
but it's not the default, not what you usually do.
On the mac there is a way, shift click or some such
that I don't remember, but again it's not what you usually do.
I want to do the same thing here.
Implement some kind of pg command, that we talked about before.
We agreed we will need some kind of control over our plugins.
It's not yet implemented, but I will soon create some kind
of pg toggle to let you access these audio web pages as plain files,
which you can download if you wish.
Basically turn the autoplay feature off.

2. If I click on it again, to hear it again,
does edbrowse really have to download it again?

It does today, but I'll probably leave it in /tmp/.edbrowse
and implement some kind of caching in the near future.
Not a full cache like other browsers, I'm probably not going to work that hard,
and we probably don't have to, but at least caching the playable files,
so if you call up the same url it already has the file and just plays it.
Of course any sort of cachine brings up nagging questions,
clearing the cache, clearing the files from /tmp/.edbrowse upon exit,
what if the sound file changes on the server, etc.
Audio files hardly ever change, as opposed to dynamic web pages,
so I'm not too worried about that one.
All this is just in my head for now,
if you want to hear it again, and click on the link again,
it downloads again.

Yes, the plugin can activate and run based on http content type,
which is where all this began.
No need to look for or rely on a suffix.
This is not true locally, as when playing songs out of a directory.
The suffix has to be there, and be correct, or you specify it with the pb command.
The thing is, the suffix usually is there for files on your computer.
It's a standard that is pretty well followed.
Adam suggested libmagic to obtain the type without the suffix,
and I like that idea, but not sure if it's worth the coding effort,
since local files tend to have the proper suffix anyways, at least I think they do,
and not sure of the portability of libmagic.

Enjoy - and let me know what bugs I've introduced.

Karl Dahlke