<p dir="ltr">Larry,<br>
I will be at LFNW. Let's get together. </p>
<div class="gmail_quote">On Apr 25, 2013 12:23 AM,  <<a href="mailto:hpr-request@hackerpublicradio.org">hpr-request@hackerpublicradio.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Send Hpr mailing list submissions to<br>
        <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:hpr-request@hackerpublicradio.org">hpr-request@hackerpublicradio.org</a><br>
You can reach the person managing the list at<br>
        <a href="mailto:hpr-owner@hackerpublicradio.org">hpr-owner@hackerpublicradio.org</a><br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Hpr digest..."<br>
<br>Today's Topics:<br>
   1. HPR Web Submission Form: Ready for first review by someone<br>
      who knows what they're doing... (<a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a>)<br>
   2. Re: HPR Web Submission Form: Ready for first review by<br>
      someone who knows what they're doing... (Ken Fallon)<br>
   3. Re: HPR Web Submission Form: Ready for first review by<br>
      someone who knows what they're doing... (Dave Morriss)<br>
   4.  HPR Web Submission Form: Ready for first review<br>
      (<a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a>)<br>
   5.   HPR Web Submission Form: Ready for first review<br>
      (<a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a>)<br>
   6. Re: HPR Web Submission Form: Ready for first review (Ken Fallon)<br>
   7. Fwd: Linux Fest Northwest (Ken Fallon)<br>
<br><br>---------- Forwarded message ----------<br>From: <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a><br>To: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>
Cc: <br>Date: Wed, 24 Apr 2013 15:44:46 -0400<br>Subject: [Hpr] HPR Web Submission Form: Ready for first review by someone who knows what they're doing...<br>I finally had time to sit down and finish getting the last bits of the first iteration of the Web-based HPR Episode Submission Form working and tested. So far it provides what I would consider "minimum useful functionality" plus one additional feature.<br>

For me, "minimum useful functionality" means that it effectively provides to the HPR admins the same materials that are currently being submitted "by hand" to the ftp server. For HPR, this should make submissions more consistent to deal with. For submitters, you'd no longer need an FTP client nor need to worry about the correct format for the show notes file.<br>

The web form guides the submitter into providing the necessary and useful information and allows upload of the show audio file, and optionally an "audio summary" file (to be prepended to the show for people who didn't read the feed before copying the file to their media player and wandering off, so they can decide if they are interested or not) and/or a single file of "supplemental" files (presumably images, example files, etc referenced in the show notes, collected into a tarball or zip file or whatever)<br>

Once uploaded, on the server side the script generates an obfuscated ID# for the submission, creates a save directory for it (as configured in the file) and saves the uploaded file(s) there, and creates a .txt file matching the format of the current show-notes file in the same directory. This provides a nice bundle of files equivalent to what the HPR admins are expecting from the FTP uploads right now for each episode, in a consistently-formatted way.<br>

In addition, the script generates as much of an Atom <entry> as it can with the given information and saves it as well. (The script cannot know some of the information required for the final <entry> such as the HPR show#, the file sizes for the encoded files, and the date the show will hit the feed - the script sticks some filler text in those spaces that should be easy to find-and-replace with the correct information at release time).<br>

The sample Atom feed file I mentioned in the last email was made with an <entry> directly generated from a test upload I did with the form (with the missing parts filled in by hand), and it is validated by the W3C online validator, so that part seems to be working. (If anyone is willing, I need to check that sample feed in as many "podcatchers" as possible. In particular, Atom allows multiple enclosures, meaning the current <entry> includes all of the media formats. I'm curious to verify that real-world "podcatcher" software is correctly handling that.)<br>

Currently, it does only slghtly more validation than the current FTP uploads get before an admin looks at them. Unmodified HTML is only allowed in a couple of explicitly configured fields. Filenames and paths are all internally generated so there shouldn't be any opening for malicious overwriting, etc. The save directory is expected to be configured to be outside of the webserver root, so the uploaded files shouldn't even be visible to anyone limited to web server access (not that this should really be an issue in our case).<br>

I've uploaded copies of the two files that make up this system to the ftp server (<a href="ftp://hackerpublicradio.org" target="_blank">ftp://hackerpublicradio.org</a> ). "hprup.php" is the actual form. "takefile.php" is the script that accepts the uploads and processes the information.<br>

To use them, both the web server and PHP will likely need their configurations updated to allow larger file uploads (the web server will need to be told how large of a chunk of POST data it should accept, and php.ini will need upload_max_filesize and post_max_size updated). The form in hprup.php should indicate what PHP is currently configured to accept as a maximum file upload size. Both files should work fine if renamed, so long as you update the form to indicate whatever you rename "takefile.php" to.<br>

Anyway: if anybody here has time to look over them for any errors or potential problems I've missed, that would be helpful. I've only done enough testing so far to see that the system actually accepts data and files and saves the information the way I expected it to, so I haven't really started prodding it for holes much yet.<br>

<br><br>---------- Forwarded message ----------<br>From: Ken Fallon <<a href="mailto:ken.fallon@gmail.com">ken.fallon@gmail.com</a>><br>To: <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a><br>
Cc: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>Date: Wed, 24 Apr 2013 22:07:26 +0200<br>Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review by someone who knows what they're doing...<br>
On Wed, 24 Apr 2013 15:44:46 -0400<br>
<a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a> wrote:<br>
> I finally had time to sit down and finish getting the last bits of<br>
> the first iteration of the Web-based HPR Episode Submission Form<br>
> working and tested. So far it provides what I would consider "minimum<br>
> useful functionality" plus one additional feature.<br>
> For me, "minimum useful functionality" means that it effectively<br>
> provides to the HPR admins the same materials that are currently<br>
> being submitted "by hand" to the ftp server. For HPR, this should<br>
> make submissions more consistent to deal with. For submitters, you'd<br>
> no longer need an FTP client nor need to worry about the correct<br>
> format for the show notes file.<br>
> The web form guides the submitter into providing the necessary and<br>
> useful information and allows upload of the show audio file, and<br>
> optionally an "audio summary" file (to be prepended to the show for<br>
> people who didn't read the feed before copying the file to their<br>
> media player and wandering off, so they can decide if they are<br>
> interested or not) and/or a single file of "supplemental" files<br>
> (presumably images, example files, etc referenced in the show notes,<br>
> collected into a tarball or zip file or whatever)<br>
> Once uploaded, on the server side the script generates an obfuscated<br>
> ID# for the submission, creates a save directory for it (as<br>
> configured in the file) and saves the uploaded file(s) there, and<br>
> creates a .txt file matching the format of the current show-notes<br>
> file in the same directory. This provides a nice bundle of files<br>
> equivalent to what the HPR admins are expecting from the FTP uploads<br>
> right now for each episode, in a consistently-formatted way.<br>
> In addition, the script generates as much of an Atom <entry> as it<br>
> can with the given information and saves it as well. (The script<br>
> cannot know some of the information required for the final <entry><br>
> such as the HPR show#, the file sizes for the encoded files, and the<br>
> date the show will hit the feed - the script sticks some filler text<br>
> in those spaces that should be easy to find-and-replace with the<br>
> correct information at release time).<br>
> The sample Atom feed file I mentioned in the last email was made with<br>
> an <entry> directly generated from a test upload I did with the form<br>
> (with the missing parts filled in by hand), and it is validated by<br>
> the W3C online validator, so that part seems to be working. (If<br>
> anyone is willing, I need to check that sample feed in as many<br>
> "podcatchers" as possible. In particular, Atom allows multiple<br>
> enclosures, meaning the current <entry> includes all of the media<br>
> formats. I'm curious to verify that real-world "podcatcher" software<br>
> is correctly handling that.)<br>
> Currently, it does only slghtly more validation than the current FTP<br>
> uploads get before an admin looks at them. Unmodified HTML is only<br>
> allowed in a couple of explicitly configured fields. Filenames and<br>
> paths are all internally generated so there shouldn't be any opening<br>
> for malicious overwriting, etc. The save directory is expected to be<br>
> configured to be outside of the webserver root, so the uploaded files<br>
> shouldn't even be visible to anyone limited to web server access (not<br>
> that this should really be an issue in our case).<br>
> I've uploaded copies of the two files that make up this system to the<br>
> ftp server (<a href="ftp://hackerpublicradio.org" target="_blank">ftp://hackerpublicradio.org</a> ). "hprup.php" is the actual<br>
> form. "takefile.php" is the script that accepts the uploads and<br>
> processes the information.<br>
> To use them, both the web server and PHP will likely need their<br>
> configurations updated to allow larger file uploads (the web server<br>
> will need to be told how large of a chunk of POST data it should<br>
> accept, and php.ini will need upload_max_filesize and post_max_size<br>
> updated). The form in hprup.php should indicate what PHP is currently<br>
> configured to accept as a maximum file upload size. Both files should<br>
> work fine if renamed, so long as you update the form to indicate<br>
> whatever you rename "takefile.php" to.<br>
> Anyway: if anybody here has time to look over them for any errors or<br>
> potential problems I've missed, that would be helpful. I've only done<br>
> enough testing so far to see that the system actually accepts data<br>
> and files and saves the information the way I expected it to, so I<br>
> haven't really started prodding it for holes much yet.<br>
> _______________________________________________<br>
> Hpr mailing list<br>
> <a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
> <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
First let me thank epicanis for the excellent work.<br>
Second. We REALLY need PHP peeps and anyone with upload experience to<br>
follow along here.<br>
@epicanis, oOne thing before I leave the train. The upload is supposed<br>
to be a complete valid atom element. So that I can do an XSLT transform<br>
- (DeepGeek Goes Wild !)<br>
<br><br>---------- Forwarded message ----------<br>From: Dave Morriss <<a href="mailto:dave.morriss@gmail.com">dave.morriss@gmail.com</a>><br>To: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>
Cc: <br>Date: Wed, 24 Apr 2013 21:18:49 +0100<br>Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review by someone who knows what they're doing...<br>On 24/04/13 21:07, Ken Fallon wrote:<br>
> @epicanis, oOne thing before I leave the train. The upload is supposed<br>
> to be a complete valid atom element. So that I can do an XSLT transform<br>
> - (DeepGeek Goes Wild !)<br>
For what it's worth, I put the sample from earlier today through<br>
xsltproc using the XSLT file I use with my podcatcher, Bashpodder. This<br>
has been modified by me to cater for Atom as well as RSS.<br>
It worked fine inasmuch as the following list of entries was displayed:<br>
<a href="http://hpr.dogphilosophy.net/audio/EP0002.opus" target="_blank">http://hpr.dogphilosophy.net/audio/EP0002.opus</a><br>
<a href="http://hackerpublicradio.org/eps/hpr1233.ogg" target="_blank">http://hackerpublicradio.org/eps/hpr1233.ogg</a><br>
<a href="http://hackerpublicradio.org/eps/hpr1233.spx" target="_blank">http://hackerpublicradio.org/eps/hpr1233.spx</a><br>
<a href="http://hackerpublicradio.org/eps/hpr1233.mp3" target="_blank">http://hackerpublicradio.org/eps/hpr1233.mp3</a><br>
I hope it helps.<br>
<br><br>---------- Forwarded message ----------<br>From: <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a><br>To: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>
Cc: <br>Date: Wed, 24 Apr 2013 17:24:15 -0400<br>Subject: [Hpr]  HPR Web Submission Form: Ready for first review<br>> The upload is supposed to be a complete valid atom element.<br>
Since some of the information is not available at upload time (show#, feed date, filesizes)<br>
there's no way to make it TRULY complete.  I could easily substitute "dummy" values for<br>
what I have currently as "#REPLACEME#"-type patterns, though. If I had the entry generated<br>
as though the show# were 0000, the filesizes were 0, and the feed release date either<br>
the same as the "published" (i.e. uploaded) date OR some obvious dummy date (one<br>
day before HPR show#1, perhaps?), that should make the feed resemble a "real" entry<br>
in format better if that would help.  (It's a pretty trivial change if you want me to do that).<br>
<br><br>---------- Forwarded message ----------<br>From: <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a><br>To: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>
Cc: <br>Date: Wed, 24 Apr 2013 17:52:36 -0400<br>Subject: [Hpr]   HPR Web Submission Form: Ready for first review<br>Update: I just did that. The Atom entry file now looks something like what I have appended at the bottom. Instead of #WHATEVER#, I'm setting the "updated" date to the same as the "published" date, and I'm assuming hostID#0000, Episode#0000, and file sizes of 0. Obviously those'll need to be updated at feed time. (I also got rid of the extra [harmless but distracting] newlines that were previously in there.)<br>

The files on the ftp server are now updated. I also put up a current copy of the two files at <a href="http://hpr.dogphilosophy.net/hprup.tar.gz" target="_blank">http://hpr.dogphilosophy.net/hprup.tar.gz</a> for anyone who wants to look.<br>

    <id><a href="http://hackerpublicradio.org/eps.php?id=0000" target="_blank">http://hackerpublicradio.org/eps.php?id=0000</a></id><br>
    <title>This Is A Test</title><br>
         <uri><a href="http://hackerpublicradio.org/correspondents.php?hostid=0000" target="_blank">http://hackerpublicradio.org/correspondents.php?hostid=0000</a></uri><br>
         <email><a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a></email><br>
    <link href="<a href="http://hackerpublicradio.org/eps.php?id=0000" target="_blank">http://hackerpublicradio.org/eps.php?id=0000</a>" /><br>
    <summary>This is another test upload.</summary><br>
    <link rel="enclosure"<br>
          type="audio/ogg; codecs=opus"<br>
          title="This Is A Test"<br>
          href="<a href="http://hackerpublicradio.org/eps/hpr0000.opus" target="_blank">http://hackerpublicradio.org/eps/hpr0000.opus</a>"<br>
          length="0" /><br>
    <link rel="enclosure"<br>
          title="This Is A Test"<br>
          href="<a href="http://hackerpublicradio.org/eps/hpr0000.ogg" target="_blank">http://hackerpublicradio.org/eps/hpr0000.ogg</a>"<br>
          length="0" /><br>
    <link rel="enclosure"<br>
          type="audio/ogg; codecs=speex"<br>
          title="This Is A Test"<br>
          href="<a href="http://hackerpublicradio.org/eps/hpr0000.spx" target="_blank">http://hackerpublicradio.org/eps/hpr0000.spx</a>"<br>
          length="0" /><br>
    <link rel="enclosure"<br>
          title="This Is A Test"<br>
          href="<a href="http://hackerpublicradio.org/eps/hpr0000.mp3" target="_blank">http://hackerpublicradio.org/eps/hpr0000.mp3</a>"<br>
          length="0" /><br>
    <content type="html"><br>
      This is just another test upload. So far this seems to be working, but knowing my luck there'll be something <em>just</em> slightly too obscure hiding in my code.<br>
We'll see. Right now I'm mainly just testing the Atom entry generation code.<br>
<br><br>---------- Forwarded message ----------<br>From: Ken Fallon <<a href="mailto:ken.fallon@gmail.com">ken.fallon@gmail.com</a>><br>To: <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a><br>
Cc: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>Date: Thu, 25 Apr 2013 08:37:00 +0200<br>Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review<br>On Wed, 24 Apr 2013 17:52:36 -0400<br>

<a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a> wrote:<br>
> Update: I just did that. The Atom entry file now looks something like<br>
> what I have appended at the bottom. Instead of #WHATEVER#, I'm<br>
> setting the "updated" date to the same as the "published" date, and<br>
> I'm assuming hostID#0000, Episode#0000, and file sizes of 0.<br>
> Obviously those'll need to be updated at feed time. (I also got rid<br>
> of the extra [harmless but distracting] newlines that were previously<br>
> in there.)<br>
OK we are getting our wires crossed. This Atom <entry> will *never*<br>
be submitted as is to the main feed. It is used to provide the metadata<br>
for the files been submitted during upload. As such everything in the<br>
Atom file should be filled out with valid values related to the<br>
*upload* only. It should also be completely valid Atom, containing<br>
accurate information in every field, to facilitate the transfer of<br>
this "pitch" to the server.<br>
So therefore:<br>
<id> This ID should be the uuid of the folder or some other globally<br>
unique id for this delivery. It should not use a HPR ID as it will<br>
never know what that is.<br>
<published> This should be the upload time<br>
<updated> Should also be the upload time, but later may be when the<br>
metadata has been updated<br>
<link> There should be no opus, ogg or spx unless those files are been<br>
transferred. This should be the file that is been uploaded (in your<br>
case) via the form. In most cases there will be one audio file (usually<br>
flac) and that's it.<br>
This will allow us to extract the xml and use that to populate the<br>
database, from there it will be used to populate other xml feeds. As<br>
the media needs to be transcoded, the <entry> would always need to be<br>
manipulated. The advantage of a well defined Atom is that it allows for<br>
validation and could also be used to import into other systems.<br>
Regarding the upload form, following fields should be removed for now:<br>
- Pre-recorded show summary audio (optional!)<br>
- Supplemental Files (if applicable)<br>
We do not have support for that as yet so let's start with what we can<br>
support and build from there.<br>
<br><br>---------- Forwarded message ----------<br>From: Ken Fallon <<a href="mailto:ken.fallon@gmail.com">ken.fallon@gmail.com</a>><br>To: "<a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a>" <<a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a>><br>
Cc: <br>Date: Thu, 25 Apr 2013 09:23:29 +0200<br>Subject: [Hpr] Fwd: Linux Fest Northwest<br><div dir="ltr">Anyone ?<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Larry Cafiero</b> <span dir="ltr"><<a href="mailto:larry.cafiero@gmail.com" target="_blank">larry.cafiero@gmail.com</a>></span><br>

Date: Thu, Apr 25, 2013 at 9:22 AM<br>Subject: Linux Fest Northwest<br>To: <a href="mailto:admin@hackerpublicradio.org" target="_blank">admin@hackerpublicradio.org</a><br><br><br><div dir="ltr"><div><div>Hi there --<br><br>
</div>Are you going to have a booth and/or someone covering Linux Fest Northwest this weekend? Just wondering because last year I spoke with a fellow who interviewed me about CrunchBang, and I wanted to let him know that I'm available again (I can't remember his name).<br>

<br></div>Thanks!.<br><br>Larry Cafiero / CrunchBang Linux<br></div>
Hpr mailing list<br>
<a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
<a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>