appcast-brainstorming - Revision history

DenisDefreyne: Redirecting appcast-brainstorming to downloads-brainstorming

2007-08-05T21:48:06Z

Redirecting appcast-brainstorming to downloads-brainstorming

← Older revision		Revision as of 21:48, 5 August 2007
Line 1:		Line 1:
	~~This appcast-brainstorming is obsolete; please visit~~ [[downloads-brainstorming]].		#REDIRECT [[downloads-brainstorming]]

DenisDefreyne: Merging appcast-brainstorming into downloads-brainstorming

2007-08-05T21:41:41Z

Merging appcast-brainstorming into downloads-brainstorming

← Older revision		Revision as of 21:41, 5 August 2007
Line 1:		Line 1:
	~~<h1>Appcast Brainstorming </h1>~~		This appcast-brainstorming is obsolete; please visit [[downloads-brainstorming]].
	~~The purpose of this page is to capture software updates practices in the wild, as one effort to codify practices currently used in the automatic update system called Sparkle.~~

	~~__TOC__~~

	~~== Authors ==~~

	* [[User:DenisDefreyne\|Denis Defreyne]]
	* [http://factoryjoe.com/ Chris Messina]

	~~== Context ==~~

	Sites like [http://iusethis.com iusethis.com], [http://versiontracker.com versiontracker.com], [http://macupdate.com macupdate.com] and [http://download.com download.com] among others should be investigated and documented for object names and attributes.

	Among common data in a software update changelog are changes or fixes, completed bugs, new features or modified behavior, and known issues. A version number is also typically supplied, but takes on many forms and is not always numeric.

	~~Lastly, this work should be seen as compatible with hAtom, possibly as a prelude to a format that could be embedded as the payload of an hfeed object.~~

	~~Work should be carried out on the [[~~appcast~~-examples \| Appcast Examples]] page.~~

	~~== Related Work ==~~

	* [[downloads-brainstorming~~]] seems to have a similar goal. Could these two pages be merged? [[User:DenisDefreyne\|DenisDefreyne]] 02:56, 28 Jul 2007 (PDT)~~
	** I would agree that they're related; ~~the Appcast work is specially aimed at making it possibly to transmit Sparkle-like updates in HTML and hAtom. I would be nice to be able to subsume the downloads work with the appcast microformat.~~ [[~~User:Chris_Messina\|Chris Messina]] 010:02, 28 Jul 2007 (CDT)~~
	** Tantek suggests that work on an appcast microformat should be continued under the name of a downloads ~~microformat, arguing that the term "appcast" is rather jargony, and I agree. [[User:DenisDefreyne\|DenisDefreyne]] 02:59, 5 Aug 2007 (PDT)~~
	* [[hash-examples]] has a section about hAtom integration. The example uses a "download" class, which contains a rel-enclosure link as well as a span with "md5" and "checksum" classes.

	~~== Sparkle-specific Appcast enhancements ==~~

	~~Sparkle adds a few extra features to appcasts:~~

	* External release notes URL: used when the release notes are not included in the appcast itself
	* MD5 sums and DSA signatures: used for some extra security
	* Version strings: Sparkle will try to determine the application version from the enclosure name, which is assumed to be APPNAME_VERSION.zip. If this is not possible, the <code>sparkle:version</code> attribute will be used. The <code>sparkle:shortVersionString</code> attribute contains the version string that will be displayed to the user (useful when the actual version number is an internal build number, for example).

	~~The appcast microformat should probably support these features as well.~~

	The MD5 sum and DSA signature is specific for an enclosure. It is, however, not possible to add these extra attributes to a [[rel-enclosure]] link. A hentry in an appcast can only have one enclosure, so the MD5 sum and DSA signature should be part of the hentry.

	~~== Proposal ==~~

	~~This proposal is mostly inspired by appcasts with Sparkle extensions.~~

	* Each hentry has one enclosure, and possibly checksums and digital signatures.
	* Each hentry has one <code>version</code> which holds the application version.

	~~Example:~~

	~~<code><pre><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">~~
	~~<html>~~
	~~<head>~~
	~~<title>Appcast</title>~~
	~~</head>~~
	~~<body>~~
	~~<h1>Appcast</h1>~~
	~~<div class="hentry">~~
	~~<h2 class="entry-title">Adium <span class="version">1.0.4</span></h2>~~
	~~<p>Updated on <abbr class="updated" title="2007-06-20T18:00+01:00">24 June</abbr>.</p>~~
	~~<div class="entry-content">~~
	~~<ul>~~
	~~<li>Fixed a crash introduced in 1.0.3 which could occur when accounts disconnected or status changed</li>~~
	~~<li>Fixed group chat when message history is enabled</li>~~
	~~</ul>~~
	~~</div>~~

	~~<p>~~
	~~<a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>.~~
	~~<span class="checksum">~~
	~~The <span class="type">MD5</span> checksum of this download is~~
	~~<span class="value">e0d123e5f316bef78bfdf5a008837577</span>.~~
	~~</span>.~~
	~~</p>~~
	~~</div>~~
	~~</body>~~
	~~</html></pre></code>~~

	~~The hash microformat used in this proposal is likely to change.~~

	~~== Multi-app/arch/OS/... appcasts ==~~

	A single downloads page can have downloads for different applications, different versions, different architectures, different operating systems, etc (for example, the [http://dev.mysql.com/downloads/mysql/5.0.html MySQL downloads page]).

	~~Here's a probably incomplete list of different download properties:~~

	* Architecture: PPC, x86, 68k, architecture-independent, …
	* OS: Mac OS X, Windows XP, OS-independent, …
	* Download type: Ruby Gem, gzipped tarball, Mac OS X DMG, …

	However, multi-* appcasts are hard to do right, and therefore probably not worth supporting. An appcast HTML page should therefore only contain updates for one application, one OS, one architecture, etc.

	~~== Issues ==~~

	* The name "appcast" is too technical ("downloads" is much more clear) and too general (because it only refers to application downloads). Renaming appcasts to downloads would solve these issues.
	* How should DSA signatures be handled? Should a simple <code><span class="dsa-signature">...</span></code> work? Should DSA signatures be part of the hash microformat (see [[hash-brainstorming]])?
	** [[digital-signatures]] seems to be useful, but only for signing microformat data, not enclosures.

	~~== Software using appcasts ==~~

	~~This is a list of programs and frameworks that use appcasts or appcast-like data.~~

	* [http://sparkle.andymatuschak.org/ Sparkle] uses Sparkle-enhanced RSS appcasts.
	* [http://metaquark.de/appfresh/ AppFresh] uses Sparkle-enhanced appcasts, including those generated by [http://iusethis.com/ iusethis] (e.g. [http://osx.~~iusethis.com/appcast/igtd the iGTD appcast]).~~

	~~== Related Pages ==~~

	* [[appcast]]
	* [[appcast-examples]]
	* [[appcast-formats]]

DenisDefreyne: Clearing up the version string section and adding reference to shortVersionString

2007-08-05T19:52:56Z

Clearing up the version string section and adding reference to shortVersionString

← Older revision		Revision as of 19:52, 5 August 2007
Line 32:		Line 32:
	* External release notes URL: used when the release notes are not included in the appcast itself		* External release notes URL: used when the release notes are not included in the appcast itself
	* MD5 sums and DSA signatures: used for some extra security		* MD5 sums and DSA signatures: used for some extra security
	* ~~Advanced version string~~: Sparkle ~~determines~~ the application version from the enclosure name, which is assumed to be APPNAME_VERSION.zip; the ~~advanced~~ version string ~~allows this convention~~ to ~~be overridden~~		* Version strings: Sparkle will try to determine the application version from the enclosure name, which is assumed to be APPNAME_VERSION.zip. If this is not possible, the <code>sparkle:version</code> attribute will be used. The <code>sparkle:shortVersionString</code> attribute contains the version string that will be displayed to the user (useful when the actual version number is an internal build number, for example).

	The appcast microformat should probably support these features as well.		The appcast microformat should probably support these features as well.

DenisDefreyne: /* Issues */

2007-08-05T13:41:10Z

Issues

← Older revision		Revision as of 13:41, 5 August 2007
Line 93:		Line 93:
	* The name "appcast" is too technical ("downloads" is much more clear) and too general (because it only refers to application downloads). Renaming appcasts to downloads would solve these issues.		* The name "appcast" is too technical ("downloads" is much more clear) and too general (because it only refers to application downloads). Renaming appcasts to downloads would solve these issues.
	* How should DSA signatures be handled? Should a simple <code><span class="dsa-signature">...</span></code> work? Should DSA signatures be part of the hash microformat (see [[hash-brainstorming]])?		* How should DSA signatures be handled? Should a simple <code><span class="dsa-signature">...</span></code> work? Should DSA signatures be part of the hash microformat (see [[hash-brainstorming]])?
			** [[digital-signatures]] seems to be useful, but only for signing microformat data, not enclosures.

	== Software using appcasts ==		== Software using appcasts ==

DenisDefreyne: Adding issues: naming (appcast vs download) and dsa signatures

2007-08-05T10:19:24Z

Adding issues: naming (appcast vs download) and dsa signatures

← Older revision		Revision as of 10:19, 5 August 2007
Line 36:		Line 36:
	The appcast microformat should probably support these features as well.		The appcast microformat should probably support these features as well.

	The MD5 sum and DSA signature is specific for an enclosure. It is, however, not possible to add these extra attributes to a [[rel-enclosure]] link~~; a larger "~~enclosure~~" microformat may~~ be ~~necessary~~.		The MD5 sum and DSA signature is specific for an enclosure. It is, however, not possible to add these extra attributes to a [[rel-enclosure]] link. A hentry in an appcast can only have one enclosure, so the MD5 sum and DSA signature should be part of the hentry.

	== Proposal ==		== Proposal ==
Line 66:		Line 66:
	<p>		<p>
	<a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>.		<a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>.
	<span class="checksum">The <span class="type">MD5</span> checksum of this download is <span class="value">e0d123e5f316bef78bfdf5a008837577</span>.</span>.		<span class="checksum">
			The <span class="type">MD5</span> checksum of this download is
			<span class="value">e0d123e5f316bef78bfdf5a008837577</span>.
			</span>.
	</p>		</p>
	</div>		</div>
Line 85:		Line 88:

	However, multi-* appcasts are hard to do right, and therefore probably not worth supporting. An appcast HTML page should therefore only contain updates for one application, one OS, one architecture, etc.		However, multi-* appcasts are hard to do right, and therefore probably not worth supporting. An appcast HTML page should therefore only contain updates for one application, one OS, one architecture, etc.

			== Issues ==

			* The name "appcast" is too technical ("downloads" is much more clear) and too general (because it only refers to application downloads). Renaming appcasts to downloads would solve these issues.
			* How should DSA signatures be handled? Should a simple <code><span class="dsa-signature">...</span></code> work? Should DSA signatures be part of the hash microformat (see [[hash-brainstorming]])?

	== Software using appcasts ==		== Software using appcasts ==

DenisDefreyne: Adding "downloads" vs. "appcast" line

2007-08-05T09:59:16Z

Adding "downloads" vs. "appcast" line

← Older revision		Revision as of 09:59, 5 August 2007
Line 23:		Line 23:
	* [[downloads-brainstorming]] seems to have a similar goal. Could these two pages be merged? [[User:DenisDefreyne\|DenisDefreyne]] 02:56, 28 Jul 2007 (PDT)		* [[downloads-brainstorming]] seems to have a similar goal. Could these two pages be merged? [[User:DenisDefreyne\|DenisDefreyne]] 02:56, 28 Jul 2007 (PDT)
	** I would agree that they're related; the Appcast work is specially aimed at making it possibly to transmit Sparkle-like updates in HTML and hAtom. I would be nice to be able to subsume the downloads work with the appcast microformat. [[User:Chris_Messina\|Chris Messina]] 010:02, 28 Jul 2007 (CDT)		** I would agree that they're related; the Appcast work is specially aimed at making it possibly to transmit Sparkle-like updates in HTML and hAtom. I would be nice to be able to subsume the downloads work with the appcast microformat. [[User:Chris_Messina\|Chris Messina]] 010:02, 28 Jul 2007 (CDT)
			** Tantek suggests that work on an appcast microformat should be continued under the name of a downloads microformat, arguing that the term "appcast" is rather jargony, and I agree. [[User:DenisDefreyne\|DenisDefreyne]] 02:59, 5 Aug 2007 (PDT)
	* [[hash-examples]] has a section about hAtom integration. The example uses a "download" class, which contains a rel-enclosure link as well as a span with "md5" and "checksum" classes.		* [[hash-examples]] has a section about hAtom integration. The example uses a "download" class, which contains a rel-enclosure link as well as a span with "md5" and "checksum" classes.

Line 75:		Line 76:
	== Multi-app/arch/OS/... appcasts ==		== Multi-app/arch/OS/... appcasts ==

	A single downloads page can have downloads for different applications, different versions, different architectures, different operating systems, etc (for example, the [http://dev.mysql.com/downloads/mysql/5.0.html MySQL downloads page]).		A single downloads page can have downloads for different applications, different versions, different architectures, different operating systems, etc (for example, the [http://dev.mysql.com/downloads/mysql/5.0.html MySQL downloads page]).

	Here's a probably incomplete list of different download properties:		Here's a probably incomplete list of different download properties:

DenisDefreyne at 09:33, 5 August 2007

2007-08-05T09:33:57Z

← Older revision		Revision as of 09:33, 5 August 2007
Line 90:		Line 90:

	* [http://sparkle.andymatuschak.org/ Sparkle] uses Sparkle-enhanced RSS appcasts.		* [http://sparkle.andymatuschak.org/ Sparkle] uses Sparkle-enhanced RSS appcasts.
	* [http://metaquark.de/appfresh/ AppFresh] uses Sparkle-enhanced appcasts ~~and~~ [http://iusethis.com/ iusethis].		* [http://metaquark.de/appfresh/ AppFresh] uses Sparkle-enhanced appcasts, including those generated by [http://iusethis.com/ iusethis] (e.g. [http://osx.iusethis.com/appcast/igtd the iGTD appcast]).
	** I'm not sure how the iusethis ~~integration works, but it looks like AppFresh scrapes HTML pages~~.
	** iusethis generate appcasts on all the ~~applications that are added, and have auto-discovering~~ appcast~~-RSS on all app pages~~.

	== Related Pages ==		== Related Pages ==

ArneFismen: /* Software using appcasts */

2007-08-04T10:04:05Z

Software using appcasts

← Older revision		Revision as of 10:04, 4 August 2007
Line 92:		Line 92:
	* [http://metaquark.de/appfresh/ AppFresh] uses Sparkle-enhanced appcasts and [http://iusethis.com/ iusethis].		* [http://metaquark.de/appfresh/ AppFresh] uses Sparkle-enhanced appcasts and [http://iusethis.com/ iusethis].
	** I'm not sure how the iusethis integration works, but it looks like AppFresh scrapes HTML pages.		** I'm not sure how the iusethis integration works, but it looks like AppFresh scrapes HTML pages.
			** iusethis generate appcasts on all the applications that are added, and have auto-discovering appcast-RSS on all app pages.

	== Related Pages ==		== Related Pages ==

DenisDefreyne: formatting cleanup

2007-08-03T13:50:26Z

formatting cleanup

← Older revision		Revision as of 13:50, 3 August 2007
Line 63:		Line 63:
	</div>		</div>

	~~<~~p><a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>. <span class="checksum">The <span class="type">MD5</span> checksum of this download is <span class="value">e0d123e5f316bef78bfdf5a008837577</span>.</span>.~~<~~/p>		<p>
			<a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>.
			<span class="checksum">The <span class="type">MD5</span> checksum of this download is <span class="value">e0d123e5f316bef78bfdf5a008837577</span>.</span>.
			</p>
	</div>		</div>
	</body>		</body>

DenisDefreyne: Changed checksum to use type/value; changing entry-version to version; removing downloads microformat in proposal; cleanup

2007-08-03T13:47:42Z

Changed checksum to use type/value; changing entry-version to version; removing downloads microformat in proposal; cleanup

← Older revision		Revision as of 13:47, 3 August 2007
Line 35:		Line 35:
	The appcast microformat should probably support these features as well.		The appcast microformat should probably support these features as well.

	The MD5 sum and DSA signature is specific for an enclosure. It is, however, not possible to add these extra attributes to a [[rel-enclosure]] link; a larger "enclosure" microformat may be necessary ~~(also see [[hash-examples]])~~.		The MD5 sum and DSA signature is specific for an enclosure. It is, however, not possible to add these extra attributes to a [[rel-enclosure]] link; a larger "enclosure" microformat may be necessary.

	== Proposal ==		== Proposal ==

	This proposal is mostly inspired by appcasts with Sparkle extensions~~. It has a few issues, mostly due to the fact that it is not "general" enough~~.		This proposal is mostly inspired by appcasts with Sparkle extensions.

	* Each hentry ~~can have~~ one ~~or more <code>download</code>s. Having more than one download in an appcast microformat used by Sparkle is not useful~~, ~~as Sparkle would only use the first enclosure it sees. It may be useful in multi-* appcasts (see below)~~.		* Each hentry has one enclosure, and possibly checksums and digital signatures.
	* Each hentry has one <code>~~entry-~~version</code> which holds the application version.		* Each hentry has one <code>version</code> which holds the application version.

	Example:		Example:
Line 54:		Line 54:
	<h1>Appcast</h1>		<h1>Appcast</h1>
	<div class="hentry">		<div class="hentry">
	<h2 class="entry-title">Adium <span class="~~entry-~~version">1.0.4</span></h2>		<h2 class="entry-title">Adium <span class="version">1.0.4</span></h2>
	<p>Updated on <abbr class="updated" title="2007-06-20T18:00+01:00">24 June</abbr>.</p>		<p>Updated on <abbr class="updated" title="2007-06-20T18:00+01:00">24 June</abbr>.</p>
	<div class="entry-content">		<div class="entry-content">
Line 62:		Line 62:
	</ul>		</ul>
	</div>		</div>
	<p ~~class="download"~~>
	<a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>.		<p><a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>. <span class="checksum">The <span class="type">MD5</span> checksum of this download is <span class="value">e0d123e5f316bef78bfdf5a008837577</span>.</span>.</p>
	MD5 ~~sum: <~~span class="~~checksum md5~~">~~0f182a2c88373e6d77c69fa15c910f08<~~/span>.
	</p>
	</div>		</div>
	</body>		</body>
	</html></pre></code>		</html></pre></code>

	~~[[User:DenisDefreyne\|DenisDefreyne]] 03:40, 1 Aug 2007 (PDT)~~		The hash microformat used in this proposal is likely to change.

	== Multi-app/arch/OS/... appcasts ==		== Multi-app/arch/OS/... appcasts ==

	A single downloads page can have downloads for different applications, different versions, different architectures, different operating systems, etc~~. The proposal above does not take this in account.~~ (~~The~~ [http://dev.mysql.com/downloads/mysql/5.0.html MySQL downloads page]~~, for example, has many apps, many architectures and many OSes.~~) ~~A way to distinguish between applications, architectures, OSes, ... would therefore be necessary~~.		A single downloads page can have downloads for different applications, different versions, different architectures, different operating systems, etc (for example, the [http://dev.mysql.com/downloads/mysql/5.0.html MySQL downloads page]).

	Here's a probably incomplete list of different download properties:		Here's a probably incomplete list of different download properties:
Line 80:		Line 78:
	* Architecture: PPC, x86, 68k, architecture-independent, …		* Architecture: PPC, x86, 68k, architecture-independent, …
	* OS: Mac OS X, Windows XP, OS-independent, …		* OS: Mac OS X, Windows XP, OS-independent, …
	* Download type: Ruby Gem, gzipped tarball, Mac OS X DMG, … ~~(Cannot use MIME types for this, as not all different download types have their own MIME type)~~		* Download type: Ruby Gem, gzipped tarball, Mac OS X DMG, …

	~~On second thought, all this is download-specific, so this is probably better suited for the [[downloads-brainstorming]] page.~~

	~~[[User:DenisDefreyne\|DenisDefreyne]] 03:40, 1 Aug 2007 (PDT)~~

	~~After having discussed this quite a bit~~, ~~I think~~ multi-* appcasts are ~~very~~ hard to do right, and therefore ~~simply~~ not worth supporting. An appcast HTML page should only contain updates for one application, one OS, one architecture, etc. ~~[[User:DenisDefreyne\|DenisDefreyne]] 03:56, 3 Aug 2007 (PDT)~~		However, multi-* appcasts are hard to do right, and therefore probably not worth supporting. An appcast HTML page should therefore only contain updates for one application, one OS, one architecture, etc.

	== Software using appcasts ==		== Software using appcasts ==
Line 100:		Line 94:
	* [[appcast]]		* [[appcast]]
	* [[appcast-examples]]		* [[appcast-examples]]
			* [[appcast-formats]]