appcast-brainstorming: Difference between revisions
(Adding "downloads" vs. "appcast" line) |
(Adding issues: naming (appcast vs download) and dsa signatures) |
||
| 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 | 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 == | ||
Revision as of 10:19, 5 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)
- 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. 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
- 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 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
versionwhich 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="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>
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 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
<span class="dsa-signature">...</span>work? Should DSA signatures be part of the hash microformat (see hash-brainstorming)?
Software using appcasts
This is a list of programs and frameworks that use appcasts or appcast-like data.
- Sparkle uses Sparkle-enhanced RSS appcasts.
- AppFresh uses Sparkle-enhanced appcasts, including those generated by iusethis (e.g. the iGTD appcast).