|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
I've completed some initial tests of the photocasting support in iPhoto 6.0. First things first: iPhoto 6.0 does not require well-formed XML, and it is very peculiar in how it supports even well-formed XML. All of Apple's photocasting extensions (currently undocumented, but see below) are supposed to live in the "http://www.apple.com/ilife/wallpapers" namespace. In Apple's photocasting feeds, this is declared on the root element: <rss version="2.0" xmlns:apple-wallpapers="http://www.apple.com/ilife/wallpapers"> So far, so good. However, I have discovered that the namespace URI is actually irrelevant; the only thing iPhoto cares about is the "apple-wallpapers" prefix. You don't even need to declare the namespace. And if you do declare the namespace but use some prefix other than "apple-wallpapers", iPhoto won't find its extension elements and it will complain. Also, iPhoto doesn't care about XML closing tags. Test cases: - no end tags (works but shouldn't): http://diveintomark.org/tests/photocast/look-ma-no-end-tags.xml - no namespace (works but shouldn't): http://diveintomark.org/tests/photocast/look-ma-no-namespace.xml - non-Apple prefix (doesn't work but should): http://diveintomark.org/tests/photocast/non-apple-prefix.xml On the subject of HTTP support (i.e. "being a good net citizen"), iPhoto sends exactly one HTTP header with its requests, a User-Agent. Mine looks like this: User-Agent: iPhoto/6.0 (Macintosh; U; PPC Mac OS X 10.4.4; English) (Obviously, this is dependent on your system configuration.) Notably absent is any support for ETags, Last-Modified headers, or gzip/zlib compression. (Feeds that are always sent gzipped will not be parsed.) iPhoto will download your whole feed, uncompressed, every time. Also, iPhoto doesn't respect 301 permanent redirects. It treats them as 302 temporary redirects, in that it will properly show the redirected content, but it will continue to poll the old URL forever. Test cases: - HTTP request headers: http://diveintomark.org/tests/photocast/http-headers-in-photo-comment.cgi - gzip compression: http://diveintomark.org/tests/photocast/gzipped.xml - 301 redirect: http://diveintomark.org/tests/photocast/301.xml On to RSS support. At the channel level, <title> is displayed as the album title in the album list. All other channel-level elements are ignored, including the (invalid) channel-level <guid> found in .Mac photocase feeds. At the item level, <title> is displayed as the photo title. <link> is displayed in the "url" field of the photo information panel, but it is *not* used for downloading. (See the apple-wallpapers section, below.) Each <category> is displayed as a photo keyword, but only if you have already defined that particular keyword in Preferences > Keywords. iPhoto will ignore all categories that are not in your locally defined keyword list. Also, item <guid> is used for caching. When the <guid> changes, iPhoto will redownload the image, even if the image URL hasn't changed. (I would say this is actually correct behavior.) All other item-level and channel-level RSS elements are ignored, including all date elements. .Mac photocast feeds contain a number of other RSS elements, but iPhoto doesn't use them. If support for RSS elements is minimal, support for Atom elements is even worse. There *is* support for Atom 1.0, in the sense that Atom 1.0 feeds are not immediately rejected, and iPhoto does actually glean some information from them. On the feed level, <atom:title> is displayed as the album title (same as RSS <title>), but only if type="text". If type="xhtml", all inline markup is stripped and the remaining text content (from any namespace) is whitespace-normalized and displayed. If type="html", all escaped markup is displayed as-is (i.e. you'll see the HTML tags on screen). On the entry level, <atom:title> is displayed as the photo title, same as RSS item <title>, with the same caveats about the @type attribute. The @href attribute from the first <atom:link> (regardless of @rel) is displayed in the "url" field of the photo information panel (but *not* used for downloading, see below). <atom:id> is used for caching, in the same manner as RSS <guid>. All other entry-level and feed-level elements are ignored, including <atom:category>. And finally, the moment you've all been waiting for (at least if you're the sort of person who has read this far)... documention on the mysterious "apple-wallpapers" namespace. As previously noted, this is not so much a namespace as a prefix, since the namespace URI is ignored and the prefix must be "apple-wallpapers". .Mac photocast feeds include a number of elements in this namespace: On the channel level, <apple-wallpapers:feedVersion> seems to always contain the value "0.9", but iPhoto seems to ignore it. Neither higher nor lower numbers trigger any sort of compatibility alert. If the element is missing completely, iPhoto doesn't seem to care. Status: optional, ignored. On the item level, <apple-wallpapers:thumbnail> is a URL for a small placeholder image that iPhoto displays while the full-size image is loading. As soon as iPhoto fetches a feed, it will attempt to download both the thumbnail and full-size image. As soon as the full-size image is downloaded, iPhoto generates its own thumbnail image out of the full-size image, and discards the <apple-wallpapers:thumbnail> image forever. Status: optional. <apple-wallpapers:image> is the URL for the full-sized image. This is the lynchpin of iPhoto's photocasting features. It *must* be present; if it's missing, iPhoto will complain that "There are no photos in the photocast <title>." .Mac feeds contain the same URL in the item <link>, but iPhoto does not use it. They also contain the same URL embedded in the item <description>, but iPhoto does not use that either. There is no fallback; it's <apple-wallpapers:image> or bust. Status: required. <apple-wallpapers:photoDate> is apparently the date the photo was taken. I can not verify how (or if) this is used or displayed. In .Mac photocasting feeds, this date does not include a timezone, making it rather useless. Status: optional. <apple-wallpapers:cropDate> is apparently the date the photo was cropped or last edited. I can not verify how (or if) this is used or displayed. Status: optional. <apple-wallpapers:metadata> contains two child elements, neither of which is in the apple-wallpapers namespace. (This has led to some heated debate among people who like to argue about this sort of thing: http://www.intertwingly.net/blog/2006/01/11/Photocasting#c1137040884 ) Within <apple-wallpapers:metadata>, the <Comments> element is displayed in the "comments" field in the photo information panel. <Comments> may only contain plain text; escaped markup will be displayed as-is. All whitespace, including carriage returns, is normalized. There is no apparent length limit; the comments field is scrollable with the keyboard but no scroll bar appears. Status: optional. Also within <apple-wallpapers:metadata> is the curious <PhotoDate> element. This is the number of days since midnight, January 1, 2000. The value can be fractional to indicate times other than midnight. The value can also be negative to indicate dates before January 1, 2000. <PhotoDate>0</PhotoDate> is displayed as "1/1/00 12:00:00 AM". There is no apparent upper limit; at least, I got bored after 9999999999, which is displayed as "6/24/5881610". There is no apparent lower limit either; -9999999999 is displayed as "6/23/-5877610". It is important to note that <PhotoDate> IS THE ONLY DATE ELEMENT THAT IPHOTO SUPPORTS. All other date elements (including, but not limited to, <pubDate>, <lastBuildDate>, <atom:updated>, <atom:published>, <apple-wallpapers:photoDate>, and <apple-wallpapers:cropDate>) are ignored. If <PhotoDate> is missing, iPhoto always displays the photo date as "12/31/2000 7:00:00 PM", for reasons that pass all understanding. Status: optional but strongly recommended. To sum up, the "photocasting" feature centers around a single undocumented extension element in a namespace that doesn't need to be declared. iPhoto 6 doesn't understand the first thing about HTTP, the first thing about XML, or the first thing about RSS. It ignores features of HTTP that Netscape 4 supported in 1996, and mis-implements features of XML that Microsoft got right in 1997. It ignores 95% of RSS and Atom and gets most of the remaining 5% wrong. -- Cheers, -Mark _______________________________________________ Do not post admin requests to the list. They will be ignored. syndication-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.