How does appcast work?

Hi community,

how do I grok appcast?

cask docs say brew can parse appcasts in sparkle, hockeyapp, devmate, sourceforge, and plain old HTML:

  • github (atom)
  • sparkle (XML)
  • hockeyapp (sparkle)
  • devmate (sparkle)
  • sourceforge (RSS)
  • HTML

github.com/atom/atom/releases.atom
updates.glyphsapp.com/appcast2.xml
rink.hockeyapp.net/api/2/apps/b36ac4a380ea4907940c2054f6163050
updates.devmate.com/com.edovia.screens4.mac.xml
sourceforge.net/projects/seashore/rss?path=/seashore%20binaries

what does brew cask do with HTML appcasts? nothing? the URL is for human eyes only?

I could clone the brew source, and flail about with find/exec/grep but this must be documented somewhere surely :sweat_smile:

It’s a very good question and I’ve wondered if it’s actually implemented fully, partially, or at all in the brew formula. I’ll post what I come across if you’ll do the same. I wouldn’t imagine that it’s not more than searching the formatting identifier for a text string, then taking the text string and comparing to a last known database of current formula for version string checking. If new string from appcast > current database string, then download file from URL identifier. Plus, many of them will have a release history. So, it could allow you to pull release notes from different past versions. However, this is just a guess since I’m about as clueless to appcast, as you are. For the few seconds that I’ve actually looked at one, it was nothing more than formatted/structured text strings. Perhaps, it can be used in not just appcast but RSS announcements, newsfeeds, etc. Again, I don’t think it’s been fully implemented, at least in all brew taps, and may only be used by devs right now.
Another thing, it may be a way to unify binaries being searched and found by different application update frameworks.

Just thought I’d add something while I was checking in on here. The appcast file is probably used by another developer, core-code, who’s app and site I just came across. I’d imagine in order for them to have so many checks spread out over multiple applications, then they’ve probably incorporated something in their framework to read these files.

You could contact them on Github or via their website to get some information or directed to it in explaining how to implement the use of different appcasts. I imagine it’d be easier, if you were checking a URL and not knowing the type of appcast, that a script deciphered this first before sending it to a parser. Appreciate if you share what you find out.

http://www.corecode.io

Hi Robert, thanks for the info, I’ll update this thread with any findings