Fraser Speirs ([info]fraserspeirs) wrote,
@ 2005-02-24 19:18:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Appcasting
Podcasting is, technologically, nothing more than using the enclosure field of an item in an RSS 2.0 feed to deliver the URL of an MP3 file which your aggregator then downloads for you.

I was thinking about setting up a development blog for FlickrExport when it occurred to me that you could use exactly the same feature of RSS 2.0 to deliver updates to an application.

For Xjournal, I wrote an embedded Software Update feature to notify users of changes, and it wouldn't yet make sense to remove that feature whilst RSS 2.0 aggregators are not all that common. However, if I were to convert the internal format of that feature to RSS 2.0 instead of Property Lists, people could subscribe to it in other ways.

One big benefit I imagine you could get from this is automatic updating of version tracking sites like Macupdate and VersionTracker. If you embedded the release notes in the body of the item, these sites could poll registered feeds and automatically update the app's notes, release date and download link.

Just a thought.

(Post a new comment)


[info]ldandersen
2005-02-24 07:27 pm UTC (link)
I'm slapping my head right now because I didn't think of this. Brilliant! I'm going to set one up for Cocoalicious.

(Reply to this) (Thread)

[info]fraserspeirs
2005-02-25 08:42 pm UTC (link)
Thanks for the support :-)

I don't suppose you could you twist your brother's arm into doing a little logo for the AppCasting concept? I'm setting up a web page describing it now.

(Reply to this) (Parent)

(Reply from suspended user)
What about macpad?
(Anonymous)
2005-02-24 08:21 pm UTC (link)
I think this is what macpad is all about: http://macshareware.net/sdk.html

I use this in VoodooPad and FlySketch, and VersionTracker + MacUpdate could both hit these files to find out release notes + other information (version, file size, date updated, etc..)

-gus

(Reply to this) (Thread)
Re: What about macpad?
[info]fraserspeirs
2005-02-24 08:39 pm UTC (link)
Interesting. I should check that out.

(Reply to this) (Parent)

[info]tumultco
2005-02-24 08:25 pm UTC (link)
This is a great idea! When read through a news reader, the entire feed would be like a version history.

I also think this would be good for beta testing if a server is setup with http-authentication. You'd only have to point the users to the feed once, instead of sending out clunky emails with difficult-to-manage email addresses.

If VT/MU doesn't get on the bandwagon, it would be very easy to put together an aggregator site which publishes updates from developer-submitted feeds.

(Reply to this) (Thread)

[info]fraserspeirs
2005-02-25 08:52 am UTC (link)
The other thing you could do is have a separate feed for beta releases....

(Reply to this) (Parent)

[info]jazzmasterson
2005-02-24 08:34 pm UTC (link)
For Xjournal, I wrote an embedded Software Update feature to notify users of changes, and it wouldn't yet make sense to remove that feature whilst RSS 2.0 aggregators are not all that common. However, if I were to convert the internal format of that feature to RSS 2.0 instead of Property Lists, people could subscribe to it in other ways.
That's a brilliant idea. Completely.

(Reply to this) (Thread)

[info]davedash
2005-02-24 10:50 pm UTC (link)
That's a great idea.

Just as a random aside, which actually is somewhat related, I wrote an app. ANd then I wrote an updater for the app. The updater would hit the server, find out what individual files had changed based on md5 signatures, and then only download those indiivdual files, makeing downloads super fast.

It lent itself well for java stuff, since there's just a ton of class files, but I'm sure the same could be done for cocoa things. But maybe saving bandwidth isn't in style anymore.

(Reply to this) (Parent)(Thread)
rsync
(Anonymous)
2005-02-25 11:22 pm UTC (link)
Dave -- you should google rsync ;)

(Reply to this) (Parent)
Brilliant!
(Anonymous)
2005-02-25 08:48 am UTC (link)
One way to tell whether any idea is brilliant or not? If, in hindsight, it's obvious, that's when...

Should be interesting to see, whether and how this idea will bear fruit.

Tom Lazar
http://tomster.org

(Reply to this)

Torrents, other things to include.
(Anonymous)
2005-02-26 01:09 am UTC (link)
This sounds like a great idea. Some thoughts:

1) BitTorrent with everything, from the start. That'll help cut down server load when new releases come out.

2) Not just updates. The RSS should have full releases, updates, and difference files (files that can turn the last release's installer into the current installer with a smaller download). People can filter with thier clients. That way, people who have to set up lots of computers could subscribe to the Firefox RSS, the AdAware RSS, the Java RSS, and so on - then you could be sure you always had all the newest binary installers ready downloaded.

This would be a great thing to have availiable!

Michael

(Reply to this) (Thread)
Re: Torrents, other things to include.
[info]fraserspeirs
2005-02-26 09:01 am UTC (link)
In principle, you can deliver your updates however makes sense. If you want to send a .torrent instead of a disk image, that's fine.

Doing the smarter stuff with patching installers rather depends on the capabilities of the aggregator you're using...

(Reply to this) (Parent)

[info]revgeorge
2005-02-27 12:00 am UTC (link)
This sounds good, but I can imagine big problems the first time someone hijacks an RSS feed and causes everyone to download a trojan. I know the W3 is working on signing XML, would it be possible to incorporate that into the Appcasts?

(Reply to this) (Thread)

[info]eichin
2005-03-01 07:35 pm UTC (link)
You should be at least be able to do "forward security" in that if you're using the binary to do the installs, it can include a public key-half that it can use to verify future downloads (it doesn't give you security ab initio, but at least if you got an ok starting point, you can validate your way forward.) Doesn't help if it's the RSS reader doing the downloads, though - but perhaps just using SSL there is enough, if the reader can be trusted to not ever do a download in the face of a certificate error or warning? (That's probably not *free* but could at least be cheap... or if you can get people to install the CACert.org CA certificate as trusted, that would let it happen for free...)

(Reply to this) (Parent)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…