Difference between revisions of "appcast-brainstorming"

From Microformats Wiki
appcast-brainstorming
Jump to navigation Jump to search
m (Not sure where the hAppcast came from, but it's gone now.)
Line 22: Line 22:
  
 
* [[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 hAppcast format. [[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)
 
* [[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 33: Line 33:
 
* 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
 
* 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
  
hAppcasts 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 (also see [[hash-examples]]).
Line 41: Line 41:
 
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. It has a few issues, mostly due to the fact that it is not "general" enough.
  
* Each hentry can have one or more <code>download</code>s. Having more than one download in a hAppcast 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 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 <code>entry-version</code> which holds the application version.
 
* Each hentry has one <code>entry-version</code> which holds the application version.
  
Line 72: Line 72:
 
[[User:DenisDefreyne|DenisDefreyne]] 03:40, 1 Aug 2007 (PDT)
 
[[User:DenisDefreyne|DenisDefreyne]] 03:40, 1 Aug 2007 (PDT)
  
== Multi-app/arch/OS/... hAppcasts ==
+
== 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. 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.

Revision as of 09:17, 3 August 2007

Appcast 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.

Authors

Context

Sites like iusethis.com, versiontracker.com, macupdate.com and 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 page.

Related Work

  • Downloads Brainstorming seems to have a similar goal. Could these two pages be merged? 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. Chris Messina 010:02, 28 Jul 2007 (CDT)
  • 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
  • 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

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).

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.

  • Each hentry can have one or more downloads. 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 entry-version which holds the application version.

Example:

<!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="entry-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 class="download">
				<a href="http://adiumx.cachefly.net/Adium_1.0.4.dmg" rel="enclosure">Download</a>.
				MD5 sum: <span class="checksum md5">0f182a2c88373e6d77c69fa15c910f08</span>.
			</p>
		</div>
	</body>
</html>

DenisDefreyne 03:40, 1 Aug 2007 (PDT)

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 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.

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, … (Cannot use MIME types for this, as not all different download types have their own MIME type)

On second thought, all this is download-specific, so this is probably better suited for the Downloads Brainstorming page.

DenisDefreyne 03:40, 1 Aug 2007 (PDT)

Related Pages