From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eklhad@comcast.net>
Received: from resqmta-ch2-01v.sys.comcast.net
 (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33])
 by hurricane.the-brannons.com (Postfix) with ESMTPS id 7364F7AC91
 for <edbrowse-dev@lists.the-brannons.com>;
 Sun, 12 Apr 2015 13:47:21 -0700 (PDT)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106])
 by resqmta-ch2-01v.sys.comcast.net with comcast
 id F8mG1q0012JGN3p018mQ8m; Sun, 12 Apr 2015 20:46:24 +0000
Received: from eklhad ([68.84.191.77])
 by resomta-ch2-10v.sys.comcast.net with comcast
 id F8mQ1q0031gep30018mQ8q; Sun, 12 Apr 2015 20:46:24 +0000
To: Edbrowse-dev@lists.the-brannons.com
From: Karl Dahlke <eklhad@comcast.net>
Reply-to: Karl Dahlke <eklhad@comcast.net>
References: <20150312120047.eklhad@comcast.net>
 <20150412193642.GH9150@toaster.adamthompson.me.uk>
User-Agent: edbrowse/3.5.3+
Date: Sun, 12 Apr 2015 16:46:08 -0400
Message-ID: <20150312164608.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=1428871584;
 bh=DVifkA+QxdHjM9zV0rKQeHVkiN4/4lyXJ0AWi5fWxnM=;
 h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID:
 Mime-Version:Content-Type;
 b=XJ3F7T4Q1lR84VEu2YD0NliydRfph5uuUFT//2NxSHZMTh2kMIGrqm41Vf2i8zn8I
 ueVLx/bbDxwOI+CJtrQ7ufZVh9xXQTrHIyfTx9keEDjhenpRgh70Bs+e9wTzaUeM1g
 Laox0c1fu4nwAQtjqQrUmdOHs9VffJSjQlE5ZmbEA1NqM0h9uikc0fRVrsQ9saPgMq
 INB4nzi0U/imTCy1gJCCuFx/H7CnGmj2LEfIzU0XQy9oXQshf3iNfA7M9i0TUYv+Ny
 41MjdEa4+bcsOAwkDPqp8xqVRmRjaDaSt1ithN27svIwtqRJHg0sLnLTjXXf0n8ZeG
 92WG/LyMIxQbQ==
Subject: [Edbrowse-dev] mailx, plugin commands, mime, new sourcefile
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: Sun, 12 Apr 2015 20:47:22 -0000

> Are we using a head request for http to determine this?

I never issue a head request, primarily because I don't need to 95%
of the time, and I never know when that other 5% is coming.
You pointed out, rightly so, that foobar.php can crank out
anything, usually it's just another web page,
wherein head would be a complete waste of time,
and maybe quite a bit of time if that php program did a lot of computatio
to get you to that next web page.
Maybe it even ordered something for you through amazon,
and issuing the command twice would order the item twice.
I don't know but messing with head commands scares me.

> I ask as in some situations I can think of,
> re-invoking the player with the URL once downloading has began may break things

Yeah I get that. That could happen.
Not sure what to say about that.
The edbrowse abort happens during the headers, not after,
and that's a worst case,
assuming it isn't redirected earlier by protocol,
but if/when this happens
most likely it would just look like a reconnect and not cause any trouble.
It's even a connect from another program, another local port,
so probably wouldn't be a problem.

> 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 is already done and has worked for quite some time.
Look at this mime descriptor from my config file.
It's also in the sample config file in the doc directory.

mime {
#  the < forces it to be a stream, hence the url is passed to the program directly
type = <audio/x-pn-realaudio
desc = streaming audio
suffix = rm,ra,ram,pls
content = audio/x-scpls
protocol = rtsp,pnm,sdp
program = /usr/bin/mplayer -quiet
}

The content = attribute is supported with the latest version,
that wasn't there before,
but it's there now and mostly works, and the other stuff worked before
and would pass the url along based on protocol or suffix.
This reminds me I need to reinstall mplayer, it's not on my new system.
Guess I don't listen to real audio very often.
I never got nasa real audio to run through mplayer,
and that bums me out cause it's not on cable any more and I
don't have any way to listen to space launches or coverage etc.
But I digress.

> I'd also like a pga option for plugins ask

Yes that's a good thought.
We should think about this one for a bit.

I added mime.c, a new sourcefile, because well it just makes sense.
I couldn't make any progress with little chunks of mime and plugin code
scattered all through the files.
So I gathered them together in mime.c, almost 300 lines of code,
and it will grow quite a bit I'm sure as we develop this important capability.
git pull and you'll see the new sourcefile.

The behavior of edbrowse is still mostly as it was before,
I've just made foundational changes,
but now I can make some real changes / improvements.

> Actually, I think even Windows provides ways for you to override the defaults for things.

Sure they do, now, after the law suit,
so they have to allow users to use maybe explorer + eudora, or perhaps firefox + outlook.
Naturally they wanted to keep you locked into their software only and forever,
but that wouldn't fly.
But I digress.

> Could you demonstrate this by *not* starting a new thread when you
> reply to this email (and all emails actually);

Ok this is a test case, it should thread up with your mailx email.
I did change the subject but I don't think that matters.
If this worked I'll make it part of my regular procedure for communication
on this list.

Karl Dahlke