It’s just data

Photocasting Hyperbole

Mark Pilgrim: 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.

For shame.  Why can’t they “Just” use XML, like everybody else does?

It turns out that they do.  Just like everybody else does.

http

I don’t know about you, but in my mind the “first thing about HTTP” is “HTTP GET”.  More specifically:

GET / HTTP/1.0

Does iPhoto 6 get this right?  Yup.  Does it get all required aspects of HTTP right?  Nothing Mark says indicates otherwise.  So what does it get wrong?

Apparently, it doesn’t include some optional headers that nothing in the RSS 2.0 spec references, and it doesn’t automatically update the location in response to a 301, something the spec says it “ought to”... “where possible”.

For shame.

The situation is a bit better in Atom 1.0.  The spec doesn’t reference these headers and status codes, but there is a set of Conformance Tests which do.

But there is one thing that they do get wrong that I’m surprised that Mark didn’t mention, particularly as the feed validator picks up on it.  They get the mime type wrong.  application/octet-stream is not defined by RFC 3023.  This is an area of confusion in RSS, again something that Atom makes a bit clearer.

I suspect that this is a result of the (somewhat misguided) attempt to be helpful.  More on that in a minute.

xml

I don’t know about you, but “the first thing about XML” is well-formedness.  Are the feeds that they produce well formed?  Yes.  Kudos.  Truth be told, not everybody consistently meet this bar.

And with one exception, they seem to be able to consume all well formed XML correctly.  That exception has to do with namespaces, something that is technically optional at the XML layer, but explicitly called out in the RSS spec, so it really should be done right.

Unfortunately, it seems that they are in good company here.

rss

So, is the feed format InvalidFairly bad Spectacularly bad?

It seems that many, if not most, feed readers can deal with photocasts already.  How can that be?

It seems that at the feed level, there are two basic problems.  Both turn out to be fairly minor.

The first is that three optional elements have dates in ISO 8601 format instead of the modified RFC 822 format that RSS 2.0 prefers.  Robust clients have long since come to realize that the RFC 822 format is troublesome, US-centric, and deprecated for new formats.  Many have come to handle ISO formatted dates. 

The other is that they include one (or three, depending on how you count) extra elements that have not been defined in the RSS 2.0 spec.  Once again, robust consumers have long since come to expect this.

And, once again, the situation is a bit better in Atom.  The one undisputed “extra” element is actually present in Atom, in fact it is required.  The other two turn out to be valid extensions in Atom.  And the date formats are ISO 8601, of which Atom’s dates are a constrained subset.  With a few minor changes, they would conform.

Net: if the unexpected elements and optional dates are ignored, the rest of the feed can be correctly consumed.  Any many consumers do.  Including Mark’s Feed Parser.

Oh, and if they ignore features of RSS and Atom that don’t apply to their application?  That’s not a bug, that’s a feature.

perspective

Clearly, being in good company doesn’t make it right, there certainly is room for improvement.  But lets put it in perspective...

If they had invented a proprietary format, we wouldn’t be having this discussion.  (Instead we would be having another one, but lets keep on track here).

But there is only one reason to pick a “standard” format (Note: I’m not going to quibble too much here), and that reason is interoperability.  Do they produce feeds that can be consumed by others?  Can others produce feeds that can be consumed by iPhoto?

The answer to the first question is largely yes, with issues that need to be worked.  But not until they find the “real feed”.

It seems that the “feed” that iPhoto prepares is not a feed at all, but rather a JavaScript application that determines if you support the format.  To be quite blunt, this is at best misguided.  But, as Phil Ringnalda noted, if this data had been correctly returned with a text/html mime type and included autodiscovery, many feed consumers would have automatically found the correct feed.  Even so, all this is entirely unnecessary... if the feed were 100% valid, there would be no reason why it couldn’t be consumed by everybody.

The answer to the second question is not very effectively without the documentation that Mark had to reverse engineer.

And those are really the two biggest issues: lack of documentation, and a somewhat distasteful and paternalistic attempt to be helpful in a way that ironically results in exactly the opposite results that one would desire — assuming that interoperability is, in fact, the goal.

Recommendations

Let’s face it, the Internet is a rough place.  If you are secretive and don’t meet up to the all the expectations of the people out there (some documented and many not), then you will be virtually burned in effigy by a lot of respected sources.

What can be done about that?  Several things.


Sam, Mark’s comments focused on iPhoto’s interpretation of RSS feeds. You commented almost exclusively on .Mac’s generation of RSS feeds. That’s why there’s such a difference in opinion here.

Posted by Graham Parks at

Graham - not quite.

HTTP - that’s 100% iPhoto’s interpretation.

XML - I talked about both sides.  And with one exception (dealing with namespaces), they can handle all types of well-formed feeds.  They just happen to be a bit more liberal than that, something I can’t imagine Mark taking offense with.

RSS - this clearly affects production and consumption.  They produce some extra data, some of it in not quite the right format, and on the consumption side they don’t rely on this data.  This seems to be a case where they tried to do the right thing, but fell a little short, and in ways that didn’t affect their application.

Perspective - I covered both sides.

Recommendation - Validation/Conformance Testing are each on one side, the rest is generic to both.

Posted by Sam Ruby at

Sam Ruby: Photocasting Hyperbole

[link]...

Excerpt from del.icio.us/miyagawa at

Sam Ruby: Fair and Balanced.

Posted by Robert Sayre at

While this new perspective is undoubtedly quite reasonable, I have to say I prefer the effigy burning.  Nobody likes being burned in effigy, and one can always hope they’ll mend their ways...

Posted by Bob Aman at

Wow.  Such a convoluted response, it’s hard to know where to start.  Or whether it’s even worth my time.  Reminds me of this, but never mind.

“Does it get all required aspects of HTTP right?”  Oh yeah, that should be the gold standard of an aggregator with a potential customer base in the millions.  Come on, Sam, we’ve all been bitching^H^H^H^H^H^H^H^Heducating people about ETag support since 2002.  Ditto gzip since 2002Permanent redirects and other HTTP status codes and a whole bunch of test cases since 2003.  It’s now 2006.  At what point are we allowed to say that “GET /” just isn’t good enough?

Your next point about XML well-formedness is self-contradictory.  In one breath you note that the .Mac feeds are served with a non-XML content type, and in the next breath you’re claiming they’re well-formed XML.  You can’t have it both ways, no matter how loudly and how often Joshua Allen and Dare Obasanjo proclaim otherwise.

As for namespace support, from the evidence I’ve collected, it is obvious to me that iPhoto is using a non-namespace-aware XML parser.  This explains why the prefix name matters so much and the namespace declaration matters not at all.  They’re simply looking for an element called “apple-wallpapers:image”, not an element represented by the tuple ("http://www.apple.com/ilife/wallpapers", “image").  Note that this (undocumented) namespaced-but-not-really element is required by iPhoto, which effectively forces all publishers who wish to interoperate to understand iPhoto’s bizarre parsing quirks.  "Everybody else has vaguely similar bugs” is not a justification.  This is, for all intents and purposes, a proprietary format.  It just happens to have angle brackets.

I don’t much care about the invalid channel-level guid, or even the wacky invalid photoDate/cropDate.  I’m only slightly peeved that they have invented yet another date format for PhotoDate, although it does mean I’ll need to write more test cases.  I already handle 28 different date formats, including Korean, Greek, and Hungarian, but I ain’t never seen a feed with a “number of days since the start of what everyone but the pedants agree is the new millenium” date before.  Hungarian?  Yeah, I can do Hungarian.  If Apple had gone with Hungarian dates, I wouldn’t have to write a single test case.  PhotoDate?  At least 3.

But I can’t get too worked up about any of that.  What really galls me is the lack of fallback behavior.  iTunes' feed parsing was spectacularly bad, but at least it didn’t require any of the iTunes extension elements for basic functionality.  If they were missing, iTunes would fall back to the appropriate core RSS elements for titles, descriptions, keywords, etc.  As a result, iTunes worked out of the box with pretty much every RSS-based podcasting feed on day 1.  iPhoto, on the other hand, absolutely requires the (undocumented) apple-wallpapers:image element, and it really strongly recommends the PhotoDate element (for sorting).  If they’re missing, you would think iPhoto could just use the enclosure element, or the link element, or even scrape the URL out of the img tag in the description to find the photo.  It could use pubDate or atom:published for the photo date.  But no, there’s no fallback.  It’s apple-wallpapers:image or bust.  PhotoDate or bust, wacky pedant-hostile date format and all.

This is what I meant when I said that iPhoto ignores 95% of RSS and Atom.  Even if you accept the shaky premise that they just had to invent their own namespace because this information is just So Damn Special, why couldn’t they fall back to core elements if their extensions were missing?  And then document the mapping (something that’s still missing from the iTunes specs, BTW).  Or, better yet, Stop Inventing Random Undocumented Crap in the first place.  But no, it’s apple-wallpapers:image or nothing.  That’s a big deal, no matter how much you try to obscure it or trivialize it.

And don’t even get me started on the user-agent-sniffing JavaScript-laden photocast.mac.com URLs that only work in Safari and iPhoto.  (Did you know they work in iPhoto?  If you paste that URL directly into iPhoto, it fetches the page and the server returns a 302 redirect to the real feed.  No HTML, no JavaScript.  But only if the user-agent is iPhoto/6.0.  So not kidding.)  I don’t attribute it to malice; I don’t think Apple is trying to “break to web” or anything so grandiose.  It simply never occurred to them to do this any other way.  They view the web as an annoyingly inadequate infrastructure on which to build their latest proprietary network, in much the same way that old-school web designers view HTML as an annoyingly inadequate page layout language.  Learning how the web works and going with its natural flow?  It simply never occurred to them.  Here’s a hint: if it takes a user-agent sniffer and 50 lines of JavaScript to load a URL, you’re swimming against the current.

Posted by Mark at

Photo RSS, Sort Of

Apple’s latest software bundle wraps RSS together with photo-publishing and they call it “Photocasting”. Reasonable enough. Dave Winer and Kevin Yank have pointed out that there are some real problems with the RSS. So Mark Pilgrim did a deep-dive...

Excerpt from ongoing at

Mark, thanks for the dailykos link.  Funniest thing I’ve read all day.

/OT

So the question is, why does Apple not get this stuff right?  It’s not like they can’t afford to hire someone to do a double check of all these things before they ship.

Posted by jacob at

From a techie viewpoint, Apple is breaking standards or at least trying to create their own standard, which sucks.

From a marketing viewpoint, if iPhoto feeds require iPhoto to view them, this may mean more people will have to buy a Mac. Which may be a perfectly plausible reason for Apple going the Microsoft way “embracing and extending” web standards.

Apart from that, every RSS aggregator application (or website) on Mac, Windows or Linux will at some time in 2006 be updated to boast the line “Now with iPhoto support”. Which means more attention for Apple.

I am not saying the ends justify the means and anyone can go free breaking web standards. I am just saying Apple may be having a different agenda from dev/tech people.

Posted by Pliep at

To me, this simply looks like a “Version 1” implementation of support for some standards.  I don’t see anything sinister here; rather, what I see is a team of developers trying to ship a working product to a deadline.  For anyone interested, there’s more on my blog entry - “Apple’s Photocasting. First Make It Work. Then Make It Work Better” @ [link]

Posted by Simon Brocklehurst at

Am I mistaken in believing this thing is serving up JPEGs? In which case, what use would gzip compression be?

Posted by Jon Dowland at

Bob:

Nobody likes being burned in effigy, and one can always hope they’ll mend their ways

I’ve seen no evidence that that has been effective.

Mark:

At what point are we allowed to say that “GET /” just isn’t good enough?

Remember, the things you write on your weblog are not spec test.  What you will find on weblogs is a bunch of contradictory and incomplete opinions complete with cat pictures.  What the Apples of the world really need is things like this to be completed and published.

Actually, I feel like the straight man in that piece of entertaining piece of Kos’ sophistry.  I do believe that mime types are important, in fact, I’m the one that added that to this discussion.  What I didn’t say was that iPhoto 6 doesn’t understand the first thing about HTTP.  It wasn’t that long ago that all of us were morons, and you know, somehow the web survived us and taught us.

Jacob:

It’s not like they can’t afford to hire someone to do a double check of all these things before they ship.

Is the Feed Validator really so hard to use that it takes hiring somebody to run it?  Come on.

Pliep:

I am just saying Apple may be having a different agenda from dev/tech people.

If so, they should be building their own protocols.  Misusing infrastructure which others depend on creates more work for everybody - including Apple.  Just to be clear, I’m in complete agreement with Mark’s substantive content.  I just think that a wee bit less hyperbole, and a bit more constructive suggestions needed to be injected into this conversation.

Simon

what I see is a team of developers trying to ship a working product to a deadline.

... virtually none of which are communicating with the outside world.  A lot of feedback that Mark and others have been providing has not only has been unheeded, much of it is virtually unacknowledged.  And, no, I don’t count the “I got your feedback, but I’m off at some conference and will get back to you” (but never do) types of responses.

Jon:

Am I mistaken in believing this thing is serving up JPEGs? In which case, what use would gzip compression be?

From my understanding based on Mark’s analysis (I don’t own a Mac), ultimately, an image will be requested once.  However before that, and presumably many times after that, your feed will be requested.  What things like ETAGs provide is a way to say “if it hasn’t changed, don’t bother sending it again”.

Posted by Sam Ruby at

They view the web as an annoyingly inadequate infrastructure on which to build their latest proprietary network, in much the same way that old-school web designers view HTML as an annoyingly inadequate page layout language.

Yes! Someone (or somethrong, really) over there seriously needs to read Motherhood and Apple Pie (in all its serendipitous titular irony).

Posted by Aristotle Pagaltzis at

Hyperbole maybe. Engaging writing... absolutely.

Posted by Darryl at

Sam wrote: A lot of feedback that Mark and others have been providing has not only has been unheeded, much of it is virtually unacknowledged.

Well, my job certainly isn’t to defend Apple or their developers; there’s never any excuse for rudeness.  And not acknowledging (polite) feedback counts as rude in my book.

Having said that, sometimes people really are overstretched. I’m sure most of us have, on occasion, let the odd e-mail slip through the net without a considered response.

Posted by Simon Brocklehurst at

What the Apples of the world really need is things like this to be completed and published.

The Atom implementation guide is called feedparser documentation.  You know as well as I do why such a guide will never be published by the Atompub working group.

Posted by Mark at

The Atom implementation guide is called feedparser documentation

All it needs now is a “Beware of the Leopard” sign.

You know as well as I do why such a guide will never be published by the Atompub working group.

First of all, I never said all conservatives are racists published by the Atompub working group.

Posted by Sam Ruby at

First of all, I never said published by the Atompub working group.

Make it an individual submission with the goal of becoming BCP, since that is exactly what it is. Submit it directly to the Area Director and we’ll dogpile it. Alternatively, submit it as a W3C Note.

Posted by Robert Sayre at

It wasn’t that long ago that all of us were morons, and you know, somehow the web survived us and taught us.

Indeed, and the web will survive this too.  It’s the “and teach us” part that I’m less sure about.  I understand that every company larger than 10 people is a really just a sprawling suburban landscape of smaller companies that don’t talk to each other, but didn’t anyone on the iPhoto development team learn anything from the iTunes podcasting disaster?  (My best-guess answer: no.  Apple treated it as a PR problem and solved it with a PR mailing list, cleverly disguised as developers mailing list.  Ha ha, the joke’s on us.)

All it needs now is a “Beware of the Leopard” sign.

And yet, amazingly, most developers who need to manage to find it anyway.  If I honestly thought that any of the people who need to read it would read it in a different venue, medium, format, or tone, I would make that happen. (On an unrelated note, I quickly searched for such a graphic to add to the feedparser.org home page, but the search results are disturbing.)

BTW, their .Mac feeds don’t validate either (and I mean before you had that fight with Rogers).  feedvalidator.org is the #1 result for “feed validator”, “rss validator”, and “rss validation”.  Perhaps you need to teach Apple’s development team how to use Google?  Or perhaps the problem is that, as I stated earlier, it never occurred to them that there were publicly available resources that could help them, so I don’t think renaming the feedparser docs to “Official RSS and Atom Implementation Guide — Hey Buddy, You Really Need To Read This Before Releasing More Undocumented Crap” is going to help.

Posted by Mark at

Sam, to quote the “moron” link, “The second faction of morons work from examples, ship code, and get yelled at... Virtually every useful tutorial in the world was written by a moron-turned-expert.”

I will continue to hope, as frankly, I am one of those morons who got yelled at, and I’ve been mending my ways.  So yeah, it can happen.

I also don’t don’t buy the “embrace and extend” analogy.

Hanlon’s Razor:

Never attribute to malice that which is adequately explained by stupidity.

Posted by Bob Aman at

Mark, it’s comments like yours that keep that mailing list from being a developer’s mailing list.  You’ve set the tenor solidly at “flamewar”.  No engineer is going to want to join that conversation, because it’s quite clear that you are going to jump all over anything that is said.  At that point it is a pr problem.  So good job there.  Apple’s other developer mailing lists are, in fact, full of developers.

Posted by john at

Mark,

As a result, iTunes worked out of the box with pretty much every RSS-based podcasting feed on day 1.  iPhoto, on the other hand, absolutely requires the (undocumented) apple-wallpapers:image element, and it really strongly recommends the PhotoDate element (for sorting).  If they’re missing, you would think iPhoto could just use the enclosure element, or the link element, or even scrape the URL out of the img tag in the description to find the photo.  It could use pubDate or atom:published for the photo date.  But no, there’s no fallback.  It’s apple-wallpapers:image or bust. 

Reportedly, flickr feeds work in iPhoto.  Are you perhaps unaware?

Posted by john at

No engineer is going to want to join that conversation,

I agree that the tenor of the conversation is a problem on that list, but it’s not the most serious problem. The comparison with other Apple mailing lists is interesting. When you bring up an issue on say, webkit-dev, you’re very likely to hear back from an engineer saying something like “oh yeah, that’s a bug, it’s in the tracker now. (bug NNNNNN)”

On syndication-dev, bug reports get a response from a project manager saying “thanks for your questions!”

Posted by Robert Sayre at

it’s comments like yours that keep that mailing list from being a developer’s mailing list.

You mean comments like these?

Which got me nothing but this:

We can’t comment or commit to specific product features before they are released. Thank you for your understanding.

So yeah, it’s obviously entirely my fault that syndication-dev isn’t just overflowing with developers.

Posted by Mark at

Az Apple RSS majomkolonia #2

Elozmenyek: zokszigen: Az Apple RSS majomkolonia, Mark Pilgrim leleplezi az Apple idiotizmusat, sonic irja: Azért érdemes elolvasni ezt is: [link]......

Excerpt from zokszigen at

XML Kerfuffles

There’s a long post (and a lot of good comments) over on Sam Ruby’s blog about the various problems with Apple’s new PhotoCast RSS Module. I find that I’m having a very hard time getting worked up about this. Sure, Apple could have done things...

Excerpt from Smalltalk Tidbits, Industry Rants at

Apple just never learns...

Depressing as usual: "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...

Excerpt from 79 Decibels at

BTW, their .Mac feeds don’t validate either (and I mean before you had that fight with Rogers).

I’m a bit surprised to see that discussion described as a fight. That wasn’t my intent; I was trying to figure out whether non-namespaced elements are properly invalid in RSS 2.0. (I know they’re invalid by my reading of the spec — I’m just not sure if that’s a good thing.)

I’m befuddled by the idea that they’re valid in Atom 1.0. If an Atom proponent could explain why that is, I’d love to hear it.

Posted by Rogers Cadenhead at

Correction: ... whether non-namespaced elements in a namespaced element are properly invalid.

Posted by Rogers Cadenhead at

RFC4287, 6.1:
  This specification describes Atom’s XML markup vocabulary.  Markup
  from other vocabularies ("foreign markup") can be used in an Atom
  Document.  Note that the atom:content element is designed to support
  the inclusion of arbitrary foreign markup.

Anything that’s not in the Atom namespace is clearly foreign markup.  Something that has no namespace isn’t in the Atom namespace.  This is why being in a namespace is an advantage.

Posted by Tim Bray at

The Problem with iPhoto

... [more]

Trackback from Eighty-Twenty

at

Rogers said:

I’m befuddled by the idea that they’re valid in Atom 1.0.

To which Tim replied:

RFC4287, 6.1:

What Tim said.  I was actually researching this a few hours ago and came to the same conclusion, and then didn’t get a chance to post it until now.  I had never actually read that part of the spec before, and was pleasantly surprised to find that it clearly and unambiguously covered this problem.  (For the record, Rogers has convinced me that the RSS spec clearly and unambiguously covers this problem too.  “A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace” is pretty clear, and it doesn’t make exceptions for non-namespaced descendants of namespaced elements.)

So Atom 1.0 “owns” all elements in the Atom namespace, while RSS 2.0 “owns” all non-namespaced elements in an RSS document.  As a general rule of thumb, I would say that extensions should live entirely in their own namespace, to maximize compatibility and minimize confusion.  But since Atom itself lives entirely in its own namespace, Apple has inadvertently designed an extension that is valid in Atom but not RSS.  And then embedded it in RSS anyway.

Don’t worry though; Sam will no doubt assure us that this isn’t the first thing developers should know about designing an RSS extension.  Maybe the second or third thing — I would venture that it’s definitely in the top 5 ("give us some fucking documentation" is probably right up there too) — but let us not venture into hyperbole by claiming that Apple doesn’t know the first thing about designing an RSS extension.

Posted by Mark at

Oh, man. What a trainwreck.

Apple Breaks RSS with Photocasting

Posted by Robert Sayre at

Another bad Apple

I’m going to have to side with Mark on this one ... there are just too many examples of Apple not getting it. It’s time they got it. I sure miss Mark’s blog, but his mailing list posts almost make up for it! Source: Sam Ruby: Photocasting Hyperbole...... [more]

Trackback from Dancing About Architecture

at

Mark attributed his article on a group of RSS dignitaries. WTF?  Name your source. Are they his friends who he calls dignitaries?

Or will he get shot if he names them.

Posted by a Journalist at

I just wanted to comment on the above comment:

And with one exception (dealing with namespaces), they can handle all types of well-formed feeds.  They just happen to be a bit more liberal than that, something I can’t imagine Mark taking offense with.

It may not seem like a bad thing that they happen to accept malformed XML, but as a large market share product, I think it is extremely important that they enforce standards now.  Do you remember a few years ago when about a quarter of the pages on the internet wouldn’t work in Firefox?  This is because Internet Explorer accepted malformed HTML pages (and still does), and many developers would only test against the de facto standard browser.  This made it extremely hard for a 3rd-party browser to break into the mass market without breaking the standard in exactly the same ways that Microsoft had.

Posted by Infomofo at

In December, Apple updated the iTunes Podcast technical specifications. Given everything else though, maybe it’s still not such a good sign...

Posted by Jay Fienberg at

trainwreck

I don’t know why we don’t call all forms of online publishing Telephone.

(Meta: blockquote passes through, but blockquote cite="..." doesn’t.)

Posted by Phil Ringnalda at

Mark attributed his article on a group of RSS dignitaries.

Nope.

$ curl -s http://lists.apple.com/archives/syndication-dev/2006/Jan/msg00020.html | grep -i dignitaries | wc -w
0

Perhaps you are are referring to the Tom Sanders article where he referred to Mark Pilgrim as an RSS dignitary?

Posted by Sam Ruby at

Apple NOT "cheating on standard"

An earlier link claimed Apple’s photocasting was not adhering to standards and got RSS “95% wrong.” Here’s the truth....

Excerpt from diggdot.us at

I enjoyed all of the comments.. and I think Apple should adhere to a common standard... when one is set in stone. THe bigger Question though is privacy..  Hold your cursor over someones name after the ‘Posted By’  and a nice tool tip comes up with their host that can easily resolve into an IP address for most of them.  That concerns me.. if there are any people with nefarious intentions out there reading these comments.

Posted by one1step1 at

Another bad Apple

I’m going to have to side with Mark on this one ... there are just too many examples of Apple not getting it. It’s time they got it. I sure miss Mark’s blog, but his mailing list posts almost make up for it! Source: Sam Ruby: Photocasting Hyperbole...

Excerpt from Dancing About Architecture (Full Content) at

Links for 2006-01-21 [del.icio.us]

[The Bible] debate goes to kids' TV Kid’s show “Nick News” to air a show on The Bible vs. Science. Sadly, no Flying Speaghetti Monster. Poor FSM! Privacy experts condemn subpoena of Google "Attorney General Alberto Gonzales rejected...

Excerpt from Cote's Drunk & Retired at

links for 2006-01-24

Achewood - January 23, 2006 “I… I’m afraid I don’t understand. Does that mean you don’t eat cheese?” (tags: comics funny) [...]...

Excerpt from 0xDECAFBAD at

Feed land

On feed crap....

Excerpt from Anne’s Weblog about Markup & Style at

Photocasting nothing new, move along

It’s been said over and over, but there seems to be some confusion. Let’s see if I can clear the air. Kudos to Steve and his team at Apple for ‘photocasting’. It’s a great name, I wish we’d thought of it....

Excerpt from smugblog: Don MacAskill at

Around the web

DDJ>The Myth of “Seven, Plus or Minus 2″ - in other words, use common sense. Why Ajax Is So Disruptive (web2.wsj2.com) About that DOJ Request (by Jeremy Zawodny) FuzzyBlog - Respond Quickly to Each and Every Comment - of course, doing...

Excerpt from alexking.org: Blog at

Greed trumps thinking differently

Apart from another dumb name from Apple (“MacBook Pro”), the underwhelming announcements in the most recent MacWorld keynote hid a really cool idea that could have changed how people used computers, had it not been saddled with an...

Excerpt from Asteroid at

Mark Pilgrim: Unofficial documentation of iPhoto 6.0 photocasting feeds

Mark Pilgrim: Unofficial documentation of iPhoto 6.0 photocasting feeds on the Apple syndication-dev mailing list. He says:To sum up, the “photocasting” feature centers around a singleundocumented extension element in a namespace that doesn’t need...

Excerpt from Irreality News at

Oh, good grief

I’m so tired of being right all the time. It was fun for a while, but now it’s just depressing....

Excerpt from dive into mark at

masklinn on Follow-up: OGG has now been removed from the HTML5 spec.

But Safari’s track records are pretty good, right? It’s not bad for the simple reason that it had to be good. It had no chance of becoming a major player in the market if it’d done any less than Firefox and Opera (and really, it’s only with

...

Excerpt from programming at

Add your comment