Autocurated Packages - Revision history

Paulproteus: /* Recommendations for other web services */ Bold, don't yell

2008-03-05T07:30:34Z

Recommendations for other web services: Bold, don't yell

← Older revision		Revision as of 07:30, 5 March 2008
Line 14:		Line 14:
	* Make it easy to get a list of CC-licensed content that you recommend!		* Make it easy to get a list of CC-licensed content that you recommend!
	** Note that "most recent uploads" is not the same as what you'd recommend. Recommendable work probably has a lot of viewers or has been hand-selected.		** Note that "most recent uploads" is not the same as what you'd recommend. Recommendable work probably has a lot of viewers or has been hand-selected.
	** ~~IMPLEMENTATION SUGGESTION~~: Make an Atom/RSS feed that links to "interesting"/recommendable content rather than just the most recent content.		** '''Implementation suggestion''': Make an Atom/RSS feed that links to "interesting"/recommendable content rather than just the most recent content.
	* Make sure it's easy for us to detect which license different works are under.		* Make sure it's easy for us to detect which license different works are under.
	** ~~IMPLEMENTATION SUGGESTION~~: Use the tech specs at [[Syndication]] for Atom and RSS.		** '''Implementation suggestion''': Use the tech specs at [[Syndication]] for Atom and RSS.
	* Don't generate broken XML or feeds. I'm happy to help you diagnose issues related to XML or feed correctness.		* Don't generate broken XML or feeds. I'm happy to help you diagnose issues related to XML or feed correctness.
	** ~~IMPLEMENTATION SUGGESTION~~: Test against an XML validator		** '''Implementation suggestion''':Test against an XML validator
	* Make it easy for us to find the raw content, not just a web page about it.		* Make it easy for us to find the raw content, not just a web page about it.
	** ~~IMPLEMENTATION SUGGESTION~~: If your RSS file contains links to HTML pages but you would rather we download a ZIP or MP3 or other file instead, use "Enclosures."		** '''Implementation suggestion''':If your RSS file contains links to HTML pages but you would rather we download a ZIP or MP3 or other file instead, use "Enclosures."

	Make sure we can get, for any work you want us to put on the disc:		Make sure we can get, for any work you want us to put on the disc:

Paulproteus at 07:29, 5 March 2008

2008-03-05T07:29:04Z

@@ Line 6: / Line 6: @@
 While there are many sites on the web, having the ability to package content on the fly is akin to packaging of an album, producing a checkout item, and is vitally important for platforms like the [[OLPC]] and [[OpenMoko]] who rely upon package management for their limited storage space.
-=== Brain Dump ===
+== Examples ==
-In a folder like 'jamendo' have the following files:
+* [[Flickr Autocuration]]
-=== Makefile ===
+== Recommendations for other web services ==
-The makefile should have basic infrastructure to ubild packages into a /packages folder
+* Make it easy to get a list of CC-licensed content that you recommend!
-'''NOTE:''' To save massive time, re-use and/or build-upon the work done on the Makefile on ccHost:
+Make sure we can get, for any work you want us to put on the disc:
- https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile
+=== Above and beyond ===
-Although, I don't think that the Makefile.language will be needed (yet) ;)
+If you'd like, you can write the autocurate module for your web service.  It should be easy to write if you know Python - a readable demo is in autocurate_flickr.py. That would make it extremely easy for us to integrate your site into the next LiveContent release.

Timothy Vollmer at 17:52, 2 October 2007

2007-10-02T17:52:44Z

← Older revision		Revision as of 17:52, 2 October 2007
Line 64:		Line 64:
	The spec file should simply use the generated tarball and Makefile to make an RPM. After this is done, then it will be easy to put these package builds, which will change possibly upon each run of the script, into a build system and for by use of RPM-based distributions.		The spec file should simply use the generated tarball and Makefile to make an RPM. After this is done, then it will be easy to put these package builds, which will change possibly upon each run of the script, into a build system and for by use of RPM-based distributions.


			=== APIs, RSS, data sources from content curators ===
			*http://flickr.com/services/api/

	=== Other Packaging System ===		=== Other Packaging System ===

Jon Phillips: /* Makefile */

2007-10-01T19:22:44Z

Makefile

← Older revision		Revision as of 19:22, 1 October 2007
Line 13:		Line 13:

	The makefile should have basic infrastructure to ubild packages into a /packages folder		The makefile should have basic infrastructure to ubild packages into a /packages folder

			'''NOTE:''' To save massive time, re-use and/or build-upon the work done on the Makefile on ccHost:

			https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile
			https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.dist
			https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.include
			https://cctools.svn.sourceforge.net/svnroot/cctools/cchost/trunk/Makefile.language

			Although, I don't think that the Makefile.language will be needed (yet) ;)

	=== Makefile.conf ===		=== Makefile.conf ===

Jon Phillips: /* Makefile.conf */

2007-10-01T19:19:13Z

Makefile.conf

← Older revision		Revision as of 19:19, 1 October 2007
Line 17:		Line 17:

	This Makefile.conf should have simple variables in the header of the file so that it is easy to target a different media hosting site and generate a new package		This Makefile.conf should have simple variables in the header of the file so that it is easy to target a different media hosting site and generate a new package

			Another idea is to have multiple confs like: openclipart.org.conf, jamendo.com.conf, and then the make dist and/or make all read in all conf's automatically...this would be useful!

	==== Features should include ====		==== Features should include ====

Jon Phillips: /* Steps to build the package */

2007-10-01T19:18:05Z

Steps to build the package

← Older revision		Revision as of 19:18, 1 October 2007
Line 27:		Line 27:

	* use curl to get content from the URL into a folder, called 'content'		* use curl to get content from the URL into a folder, called 'content'
	* make packages from this content folder like the following		* make packages from this content folder like the following, into directory, called 'packages'
	** jamendo_`date +%F`.tar.gz		** jamendo_`date +%F`.tar.gz
	** jamendo_`date +%F`.tar.bz2		** jamendo_`date +%F`.tar.bz2
Line 36:		Line 36:
	* create .deb with alien or the like, or directly		* create .deb with alien or the like, or directly
	** jamendo_`date +%F`.deb		** jamendo_`date +%F`.deb

			To generate all packages:

			make dist

			To generate specific {tar.gz,tar.bz2,zip,xo1,rpm,deb,ebuild} package:

			make PACKAGE_TYPE

			Example:

			make xo1

	=== .spec file ===		=== .spec file ===

Jon Phillips: /* Makefile */

2007-10-01T19:15:42Z

Makefile

← Older revision		Revision as of 19:15, 1 October 2007
Line 12:		Line 12:
	=== Makefile ===		=== Makefile ===

	~~This Makefile~~ should have ~~simple variables in the header of the file so that it is easy~~ to ~~target~~ a ~~different media hosting site and generate a new package~~		The makefile should have basic infrastructure to ubild packages into a /packages folder

	Features should include:		=== Makefile.conf ===

			This Makefile.conf should have simple variables in the header of the file so that it is easy to target a different media hosting site and generate a new package

			==== Features should include ====

	* variable NUM_OF_FILES=10		* variable NUM_OF_FILES=10
Line 20:		Line 24:
	* variable URL, like URL=http://jamendo.com/get?toptracks&num=${NUM_OF_FILES}&license=${LICENSE}		* variable URL, like URL=http://jamendo.com/get?toptracks&num=${NUM_OF_FILES}&license=${LICENSE}

	Steps to build the package:		==== Steps to build the package ====

	* use curl to get content from the URL into a folder, called 'content'		* use curl to get content from the URL into a folder, called 'content'

Jon Phillips: /* Makefile */

2007-10-01T18:30:13Z

Makefile

← Older revision		Revision as of 18:30, 1 October 2007
Line 27:		Line 27:
	** jamendo_`date +%F`.tar.bz2		** jamendo_`date +%F`.tar.bz2
	** jamendo_`date +%F`.zip		** jamendo_`date +%F`.zip
			** jamendo_`date +%F`.xo1 (zip for olpc)
	* call .spec file to make rpms		* call .spec file to make rpms
	** jamendo_`date +%F`.rpm		** jamendo_`date +%F`.rpm
			* create .deb with alien or the like, or directly
			** jamendo_`date +%F`.deb

	=== .spec file ===		=== .spec file ===

Jon Phillips: /* Brain Dump = */

2007-10-01T18:26:20Z

Brain Dump =

← Older revision		Revision as of 18:26, 1 October 2007
Line 6:		Line 6:
	While there are many sites on the web, having the ability to package content on the fly is akin to packaging of an album, producing a checkout item, and is vitally important for platforms like the [[OLPC]] and [[OpenMoko]] who rely upon package management for their limited storage space.		While there are many sites on the web, having the ability to package content on the fly is akin to packaging of an album, producing a checkout item, and is vitally important for platforms like the [[OLPC]] and [[OpenMoko]] who rely upon package management for their limited storage space.

	== Brain Dump ===		=== Brain Dump ===

	In a folder like 'jamendo' have the following files:		In a folder like 'jamendo' have the following files:

Jon Phillips: New page: Category:LiveContent Category:Developer The idea of auto-curated packages is that high-quality content can be pulled from media hosting sites that support a RESTful API for gettin...

2007-07-12T22:28:29Z

New page: Category:LiveContent Category:Developer The idea of auto-curated packages is that high-quality content can be pulled from media hosting sites that support a RESTful API for gettin...

New page

[[Category:LiveContent]]
[[Category:Developer]]

The idea of auto-curated packages is that high-quality content can be pulled from media hosting sites that support a RESTful API for getting CC licensed content. The community from these sites has peer reviewed content so that it makes it easy to automatically pull down a top ten best tracks, or something similar, and then timestamp them, and package them for inclusion onto various devices.

While there are many sites on the web, having the ability to package content on the fly is akin to packaging of an album, producing a checkout item, and is vitally important for platforms like the [[OLPC]] and [[OpenMoko]] who rely upon package management for their limited storage space.

== Brain Dump ===

In a folder like 'jamendo' have the following files:

=== Makefile ===

This Makefile should have simple variables in the header of the file so that it is easy to target a different media hosting site and generate a new package

Features should include:

* variable NUM_OF_FILES=10
* variable LICENSE=BY
* variable URL, like URL=http://jamendo.com/get?toptracks&num=${NUM_OF_FILES}&license=${LICENSE}

Steps to build the package:

* use curl to get content from the URL into a folder, called 'content'
* make packages from this content folder like the following
** jamendo_`date +%F`.tar.gz
** jamendo_`date +%F`.tar.bz2
** jamendo_`date +%F`.zip
* call .spec file to make rpms
** jamendo_`date +%F`.rpm

=== .spec file ===

The spec file should simply use the generated tarball and Makefile to make an RPM. After this is done, then it will be easy to put these package builds, which will change possibly upon each run of the script, into a build system and for by use of RPM-based distributions.

=== Other Packaging System ===

Also, there could easily be wrapper scripts for generating .deb packages necessary for debian-based distributions like Ubuntu. One can use the program 'Alien' to convert from an RPM to a .deb package.

Also, gentoo ebuilds would be another interesting target.