[Hpr] HPR Web Submission Form: Ready for first review

Ken Fallon ken.fallon at gmail.com
Wed Apr 24 23:37:00 PDT 2013


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.





More information about the Hpr mailing list