Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Unofficial documentation of iPhoto 6.0 photocasting feeds
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Unofficial documentation of iPhoto 6.0 photocasting feeds



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.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.