[Hpr] Larry C the CRUNCHBANG GUY

Ken Fallon ken.fallon at gmail.com
Thu Apr 25 08:39:56 PDT 2013


Hi Larry,

David will be there.

Ken.


On Thu, Apr 25, 2013 at 1:40 PM, David Whitman
<davidglennwhitman at gmail.com>wrote:

> Larry,
> I will be at LFNW. Let's get together.
> On Apr 25, 2013 12:23 AM, <hpr-request at hackerpublicradio.org> wrote:
>
>> Send Hpr mailing list submissions to
>>         hpr at hackerpublicradio.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>
>> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>>
>> or, via email, send a message with subject or body 'help' to
>>         hpr-request at hackerpublicradio.org
>>
>> You can reach the person managing the list at
>>         hpr-owner at hackerpublicradio.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Hpr digest..."
>>
>> Today's Topics:
>>
>>    1. HPR Web Submission Form: Ready for first review by someone
>>       who knows what they're doing... (epicanis+hpr at dogphilosophy.net)
>>    2. Re: HPR Web Submission Form: Ready for first review by
>>       someone who knows what they're doing... (Ken Fallon)
>>    3. Re: HPR Web Submission Form: Ready for first review by
>>       someone who knows what they're doing... (Dave Morriss)
>>    4.  HPR Web Submission Form: Ready for first review
>>       (epicanis+hpr at dogphilosophy.net)
>>    5.   HPR Web Submission Form: Ready for first review
>>       (epicanis+hpr at dogphilosophy.net)
>>    6. Re: HPR Web Submission Form: Ready for first review (Ken Fallon)
>>    7. Fwd: Linux Fest Northwest (Ken Fallon)
>>
>>
>> ---------- Forwarded message ----------
>> From: epicanis+hpr at dogphilosophy.net
>> To: hpr at hackerpublicradio.org
>> Cc:
>> Date: Wed, 24 Apr 2013 15:44:46 -0400
>> Subject: [Hpr] HPR Web Submission Form: Ready for first review by someone
>> who knows what they're doing...
>> 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.
>>
>> 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.
>>
>> 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)
>>
>> 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.
>>
>> 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).
>>
>> 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.)
>>
>> 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).
>>
>> I've uploaded copies of the two files that make up this system to the ftp
>> server (ftp://hackerpublicradio.org ). "hprup.php" is the actual form.
>> "takefile.php" is the script that accepts the uploads and processes the
>> information.
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Ken Fallon <ken.fallon at gmail.com>
>> To: epicanis+hpr at dogphilosophy.net
>> Cc: hpr at hackerpublicradio.org
>> Date: Wed, 24 Apr 2013 22:07:26 +0200
>> Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review by
>> someone who knows what they're doing...
>> On Wed, 24 Apr 2013 15:44:46 -0400
>> epicanis+hpr at dogphilosophy.net wrote:
>>
>> > 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.
>> >
>> > 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.
>> >
>> > 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)
>> >
>> > 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.
>> >
>> > 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).
>> >
>> > 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.)
>> >
>> > 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).
>> >
>> > I've uploaded copies of the two files that make up this system to the
>> > ftp server (ftp://hackerpublicradio.org ). "hprup.php" is the actual
>> > form. "takefile.php" is the script that accepts the uploads and
>> > processes the information.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > _______________________________________________
>> > Hpr mailing list
>> > Hpr at hackerpublicradio.org
>> > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>>
>>
>> First let me thank epicanis for the excellent work.
>>
>> Second. We REALLY need PHP peeps and anyone with upload experience to
>> follow along here.
>>
>> @epicanis, oOne thing before I leave the train. The upload is supposed
>> to be a complete valid atom element. So that I can do an XSLT transform
>> - (DeepGeek Goes Wild !)
>>
>> Ken
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Dave Morriss <dave.morriss at gmail.com>
>> To: hpr at hackerpublicradio.org
>> Cc:
>> Date: Wed, 24 Apr 2013 21:18:49 +0100
>> Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review by
>> someone who knows what they're doing...
>> On 24/04/13 21:07, Ken Fallon wrote:
>> > @epicanis, oOne thing before I leave the train. The upload is supposed
>> > to be a complete valid atom element. So that I can do an XSLT transform
>> > - (DeepGeek Goes Wild !)
>>
>> For what it's worth, I put the sample from earlier today through
>> xsltproc using the XSLT file I use with my podcatcher, Bashpodder. This
>> has been modified by me to cater for Atom as well as RSS.
>>
>> It worked fine inasmuch as the following list of entries was displayed:
>>
>> http://hpr.dogphilosophy.net/audio/EP0002.opus
>> http://hackerpublicradio.org/eps/hpr1233.ogg
>> http://hackerpublicradio.org/eps/hpr1233.spx
>> http://hackerpublicradio.org/eps/hpr1233.mp3
>>
>> I hope it helps.
>>
>> Dave
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: epicanis+hpr at dogphilosophy.net
>> To: hpr at hackerpublicradio.org
>> Cc:
>> Date: Wed, 24 Apr 2013 17:24:15 -0400
>> Subject: [Hpr] HPR Web Submission Form: Ready for first review
>> > The upload is supposed to be a complete valid atom element.
>>
>> Since some of the information is not available at upload time (show#,
>> feed date, filesizes)
>> there's no way to make it TRULY complete.  I could easily substitute
>> "dummy" values for
>> what I have currently as "#REPLACEME#"-type patterns, though. If I had
>> the entry generated
>> as though the show# were 0000, the filesizes were 0, and the feed release
>> date either
>> the same as the "published" (i.e. uploaded) date OR some obvious dummy
>> date (one
>> day before HPR show#1, perhaps?), that should make the feed resemble a
>> "real" entry
>> in format better if that would help.  (It's a pretty trivial change if
>> you want me to do that).
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: epicanis+hpr at dogphilosophy.net
>> To: hpr at hackerpublicradio.org
>> Cc:
>> Date: Wed, 24 Apr 2013 17:52:36 -0400
>> Subject: [Hpr] HPR Web Submission Form: Ready for first review
>> 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.)
>>
>> The files on the ftp server are now updated. I also put up a current copy
>> of the two files at http://hpr.dogphilosophy.net/hprup.tar.gz for anyone
>> who wants to look.
>>
>> <entry>
>>     <id>http://hackerpublicradio.org/eps.php?id=0000</id>
>>     <title>This Is A Test</title>
>>     <updated>2013-04-24T23:41:21+02:00</updated>
>>     <published>2013-04-24T23:41:21+02:00</published>
>>     <author>
>>          <name>Epicanis</name>
>>          <uri>http://hackerpublicradio.org/correspondents.php?hostid=0000
>> </uri>
>>          <email>epicanis+hpr at dogphilosophy.net</email>
>>     </author>
>>
>>     <link href="http://hackerpublicradio.org/eps.php?id=0000" />
>>     <summary>This is another test upload.</summary>
>>     <link rel="enclosure"
>>           type="audio/ogg; codecs=opus"
>>           title="This Is A Test"
>>           href="http://hackerpublicradio.org/eps/hpr0000.opus"
>>           length="0" />
>>     <link rel="enclosure"
>>           type="audio/ogg"
>>           title="This Is A Test"
>>           href="http://hackerpublicradio.org/eps/hpr0000.ogg"
>>           length="0" />
>>     <link rel="enclosure"
>>           type="audio/ogg; codecs=speex"
>>           title="This Is A Test"
>>           href="http://hackerpublicradio.org/eps/hpr0000.spx"
>>           length="0" />
>>     <link rel="enclosure"
>>           type="audio/mpeg"
>>           title="This Is A Test"
>>           href="http://hackerpublicradio.org/eps/hpr0000.mp3"
>>           length="0" />
>>     <content type="html">
>>       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.
>>
>> We'll see. Right now I'm mainly just testing the Atom entry generation
>> code.
>>
>>     </content>
>> </entry>
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Ken Fallon <ken.fallon at gmail.com>
>> To: epicanis+hpr at dogphilosophy.net
>> Cc: hpr at hackerpublicradio.org
>> Date: Thu, 25 Apr 2013 08:37:00 +0200
>> Subject: Re: [Hpr] HPR Web Submission Form: Ready for first review
>> On Wed, 24 Apr 2013 17:52:36 -0400
>> epicanis+hpr at dogphilosophy.net wrote:
>>
>> > 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.)
>>
>> OK we are getting our wires crossed. This Atom <entry> will *never*
>> be submitted as is to the main feed. It is used to provide the metadata
>> for the files been submitted during upload. As such everything in the
>> Atom file should be filled out with valid values related to the
>> *upload* only. It should also be completely valid Atom, containing
>> accurate information in every field, to facilitate the transfer of
>> this "pitch" to the server.
>>
>> So therefore:
>> <id> This ID should be the uuid of the folder or some other globally
>> unique id for this delivery. It should not use a HPR ID as it will
>> never know what that is.
>> <published> This should be the upload time
>> <updated> Should also be the upload time, but later may be when the
>> metadata has been updated
>> <link> There should be no opus, ogg or spx unless those files are been
>> transferred. This should be the file that is been uploaded (in your
>> case) via the form. In most cases there will be one audio file (usually
>> flac) and that's it.
>>
>> This will allow us to extract the xml and use that to populate the
>> database, from there it will be used to populate other xml feeds. As
>> the media needs to be transcoded, the <entry> would always need to be
>> manipulated. The advantage of a well defined Atom is that it allows for
>> validation and could also be used to import into other systems.
>>
>> Regarding the upload form, following fields should be removed for now:
>> - Pre-recorded show summary audio (optional!)
>> - Supplemental Files (if applicable)
>> We do not have support for that as yet so let's start with what we can
>> support and build from there.
>>
>>
>> Ken.
>>
>>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Ken Fallon <ken.fallon at gmail.com>
>> To: "hpr at hackerpublicradio.org" <hpr at hackerpublicradio.org>
>> Cc:
>> Date: Thu, 25 Apr 2013 09:23:29 +0200
>> Subject: [Hpr] Fwd: Linux Fest Northwest
>> Anyone ?
>>
>> ---------- Forwarded message ----------
>> From: Larry Cafiero <larry.cafiero at gmail.com>
>> Date: Thu, Apr 25, 2013 at 9:22 AM
>> Subject: Linux Fest Northwest
>> To: admin at hackerpublicradio.org
>>
>>
>> Hi there --
>>
>> 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).
>>
>> Thanks!.
>>
>> Larry Cafiero / CrunchBang Linux
>>
>>
>> _______________________________________________
>> Hpr mailing list
>> Hpr at hackerpublicradio.org
>> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>>
>>
> _______________________________________________
> Hpr mailing list
> Hpr at hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/attachments/20130425/3f2097c1/attachment-0006.html>


More information about the Hpr mailing list