You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Feature request #1388: Atom feeds for products (for Sparkle-like product updates)

Kind feature request
Product wincent.dev
When Created , updated
Status open
Reporter Greg Hurrell
Tags appcast

Description

The products#index action currently doesn't do anything interesting but eventually will want the Atom format to serve as a kind of all-product AppCast.

Likewise for each product we'll want the Atom format of products#show to be a per-product AppCast.

Comments

  1. Greg Hurrell

    Tags changed:

    • From:
    • To: appcast
  2. Greg Hurrell

    Note that officially an AppCast is based on the "enclosure" feature of RSS and I use Atom for everything. Will have to look into that and see if there are any technical obstacles.

  3. Greg Hurrell

    Summary changed:

    • From: Atom feeds for products
    • To: Atom feeds for products (for Sparkle-like product updates)
  4. Greg Hurrell

    Looks like using Atom would require a minor re-invention of the wheel, seeing as the most popular self-update framework out there (Sparkle) uses only RSS.

    As far as having the products#index Atom format deliver "appcast" style info, it's probably not such an interesting feature seeing as the only clients which would realistically hit such a URL would be the apps themselves, and they may as well hit the per-app feeds.

    So I am thinking that it should probably be a more human-readable feed, with release notifications and a link to the appropriate release page.

    The per-product feeds are the interesting ones, and I am now thinking that I'll want a new "Release" model as a nested resource under products. e.g. you would hit /products/synergy/releases.atom for the appcast for Synergy, and /products/synergy/releases/4.3 would show you either metadata for the release or just the release notes themselves (ie a PDF, RTF, HTML or whatever file).

    To create a new release you'd really need to provide two things — the downloadable asset and the release notes — in addition to the actual version string.

    I don't think I necessarily need Rails to serve up the assets, but I would like to keep count of the number of times resources were fetched. Perhaps it would be a good idea to make this a non-RESTful resource, so that I could have URLs like:

    • /products/synergy/releases/4.3/notes (release notes in "native" format: PDF, HTML, RTF etc)
    • /products/synergy/releases/4.3/dmg (downloadable disk image)

    In this way I could keep count of how many people viewed the release notes from within the app, and compare it with how many actually proceeded to download it. Hitting those URLs would just increment the counter and then redirect to the real download URL, which would then just be served up by nginx. As such, creating new releases would involve first uploading the resources and then setting up the release model. I am not sure whether this is ideal, or whether I should set up some kind of upload mechanism within the app.

    I could also replace the existing links (using the "Link" model) on the downloads page with links to the "releases" resources. I don't think I would go so far as to replace the hand-coded downloads page with a link to the /products/synergy/releases page, because I do value the ability to add additional information to the page.

  5. Greg Hurrell

    Another thought: if we decide to be more flexible than hard-wiring the expectation about having release notes and a downloadable archive, then we would require another nested resource. I've already got an "attachments" resource in the works for use with the issue tracker. Perhaps that could be used for this purpose. Or, if that is too fiddly, may need to add another "Asset" resource. Will have to think about it.

    This is probably a fairly desirable feature because it would allow me to offer a number of downloadable assets with each release (the archive itself, release notes, maybe a localization pack, for example).

    I guess the appcast feed would just need to point to the appropriate URLs for the release notes and the archive.

  6. Greg Hurrell

    For reference, the ticket for the "attachment" feature is ticket #1193.

  7. Greg Hurrell

    Been playing with Sparkle today and I fear I can't really drop it in as-is. Some wheel re-invention, regrettably, may be required.

    As a first step anyway, I want to get this "Releases" model in place so that I can get my app feeds published.

  8. Greg Hurrell

    Cursory examination of http://www.atomenabled.org/developers/syndication:

    Basic structure of the feed:

    • <feed>
      • <id> (required): unique, permanent, identifying URL for the feed
      • <title> (required)
      • <updated> (required)
      • <author> (recommended)
      • <link>(recommended): related web page
    • <entry>
      • <id> (required): unique, permanent, identifying URL for entry
      • <title>(required): human-readable, non-blank title for entry
      • <update> (required): last significant (ie not just a typo fix) modification
      • <author> (recommended)
      • <link> (recommended)
        • can use the enclosure (see below)
        • can also provide an alternate web page for more info (eg. <link rel="alternate" href="/products/synergy/releases/5.0">)
      • <summary> (recommended, "should be provided if ... content is not inline")
      • <content> (recommended): "Contains or links to the complete content of the entry"; can probably be skipped as "Content must be provided if there is no alternate link, and should be provided if there is no summary", but we will provide both
      • <published> (optional): original publication date

    <link> element

    Our <entry> elements will need to have <link> elements of the form: 

    <link href="..."
      rel="enclosure" 
      title="Synergy 5.0"
      length="1743241" />

    <content> element

    Note that if we want to insert additional meta info such as minimum OS requirement or such, "[t]he atom content element is designed to support the direct inclusion of other XML vocabularies."

    Otherwise, if the type attribute ends in +xml or /xml, then an xml document of this type is contained inline.

    So we can really pack anything we need in there.

  9. Greg Hurrell

    Example appcasting format built on top of Atom:

    <entry xmlns="http://www.w3.org/2005/Atom"
            xmlns:appcast="http://pandion.im/protocol/appcast/1.0"
            appcast:name="Pandion"
            appcast:track="development"
            appcast:version="2.6.84">
<title>Update: Pandion 2.6.84</title>
<summary type="html">Development build</summary>
<id>urn:uuid:e01a5712-aa81-466d-ac9f-f2fabfd11886</id>
<published>2010-02-13T16:25:59.942+01:00</published>
<updated>2010-02-13T16:25:59.942+01:00</updated>
<link appcast:arguments="/passive LAUNCHAPP=yes"
      href="http://downloads.sourceforge.net/project/pandion/builds/Pandion_2.6.84.msi"
      length="1801676"
      rel="enclosure"
      title="Pandion 2.6.84"
      type="application/x-msi" />
<link href="http://build.pandion.im/job/Pandion/84/changes"
      rel="alternate"
      title="Release Notes"
      type="text/html" />
</entry>
  10. Greg Hurrell
  11. Greg Hurrell
  12. Greg Hurrell
  13. Greg Hurrell

    Elements/attributes that I'll need to add to the custom appcast namespace:

    • product: so that I can have an all-products feed if I desire with different <entry> elements corresponding to different products
    • minimum system version
    • maximum system version
    • type (release, beta, alpha, nightly): so users can subscribe to different levels of stability
    • autoupdate/noautoupdate (boolean): there may be major updates that I don't ever want to apply automatically, and always want the user to approve before clicking "Install" (ie. paid upgrades, major new releases with backwards compatibility breaking changes etc)
    • platform/arch: again, this may come in handy if a product ever switches from ppc/i386 to, say, i386/x86_64 etc
    • digest: for the download
    • signature: cryptographically sign the download (so digest itself is probably redundant)
    • version (feed-level addition): the version number of the Atom extension itself, just in case I ever need to change it
    • version (entry-level addition): machine-readable version number so that the applications can decide whether the entry refers to a newer version or not (done by comparison with Info.plist values)
Add a comment

Comments are now closed for this issue.

Menu