Slashdot Mirror

It's not that hard. There are plenty of programs to generate such patterns, Sam Ruby wrote a nice one in SVG and ECMAScript. It generates it (deliberately) one tile at a time for a cool animation, doing the same as a background would probably be too distracting.

AFAIK there is already a working HTML5 conform 3D implementation based on WebGL and the X3D standard. It's called X3DOM (http://x3dom.org).

There's no need for a separate build of Firefox when an HTML5 conform implementation will work out of the box in Firefox 3.7 via WebGL. There's already an official bug by Sam Ruby (http://intertwingly.net/blog/2009/11/05/Web3D) in the W3C bug tracker (http://www.w3.org/Bugs/Public/show_bug.cgi?id=8238).

My understanding is that one should set up OpenID delegation, which allows you to have a static OpenID but still use third-party providers for the authentication portion. Anyone with a web presence can do this, and it's actually preferred to hosting your own OpenID server since it shows that someone else also vouches that you are who you say you are. Here is some further reading.

The vector graphics in Silverlight is similar enough to SVG to be converted by a relatively simple Javascript.

The scenario they seem to be enabling for SVG is inline SVG with HTML content (not XHTML). This means that you can install the Adobe SVG Viewer and have it render the inline SVG within the HTML page. Unfortunately it seems like there may be some implementation issues with it (possibly preventing the xlink namespace within the SVG). See the now-available whitepaper and the discussion here

JSON is fit mostly for communication and transfer of simple data between JS and server side scripts through object serialization. But it remains limited. You can compare JSON to XML only if your knowledge of XML stops at the X in AJAX
Beyond that scope comparing these two unrelated "things" is irrelevant.

The tools and libraries available for XML go well beyond JSON's scope. DOM, RSS & ATOM, OASIS, Xpath, XSLT, eXist DB are just few examples of tools and libraries surrounding XML.
XML is designed to let you create your own protocols and formats while using only one simple base format (XML), one simple descriptor language (Schema or DTS) and you can convert your formats and protocols using one transformation technology (XSLT).
There are languages to query XML files and collections, XLM databases and many more examples including scientific, vectorial and 3d imaging formats.
I believe the word Interoperability was created with XML in mind... Or maybe the other way round... whatever.

Already written

http://www.intertwingly.net/blog/2007/09/01/2to3

Continuations is simply a modern term for GOTOs...

Maybe if you manage all of the memory management manually and implement your own frame storage and reclamation strategy.... (I like Sam Ruby's Continuations for Curmudgeons.)

Java was born to be an OO language.

Love those primitive types! (Smalltalk seemed to do okay without them.)

The central problem with this entire stink is considering iPhoto as an RSS client. It is not an RSS client.

iPhoto is a Photocast client. It is only designed to accept and work with Photocasts. Note that I am capitalizing Photocast as it is a proprietary name for a propietary service.

As Sam Ruby points out here, Photocast feed generation hews closely enough to standards to allow any reasonably good RSS client to accept and interpret Photocasts. This is pretty close to what Jobs advertised in the keynote--anyone with an RSS client can subscribe to your Photocasts.

What he did not promise is that iPhoto is now a standards-compliant client for all RSS feeds. So I have a hard time understanding why it's being held to that standard.

Photocasts are available as feeds but are not in and of themselves standard-compliant feeds. Further, I don't see why they need to be. I can see why it would be nice and ideal, but that is a different conversation (what Apple "should" do vs. what Apple has "failed" to do).

There's a much more balanced review of this here: http://intertwingly.net/blog/2006/01/18/Photocasti ng-Hyperbole/

Summary: Before putting software on umpteen desktops that is intended to interoperate with other vendors' code, Apple should have a beta release and take note of the feedback.

Sound practical?

You might be interested in a quote from a comment on Sam Ruby's article on this matter:

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.

What the hell is Atom and who supports it?

Atom is "an XML-based document format that describes lists of related information known as "feeds"" ... with the primary use case of "the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents", as specified in RFC 4287. And it's supported by... well, pretty much everything out there.

If you read the RFC, you will also see that Atom is superbly well-specified. Back in the Atom 0.3 days, I implemented both an RSS feed and an Atom feed, and ever since I've stuck to implementing solely Atom feeds, as information about RSS is scattered everywhere, and you need to specify, for example, half a dozen mutually-incompatible and differently-formatted date elements just to be certain that the correct date of an entry is understood everywhere. And that's the easy part.

I happen to have RSS on the brain at the moment, since I just this week implemented RSS 2.0 for my personal webpage. The comments on the linked articles mostly go like this:

- It works for me!
- It doesn't matter that it works for you; it violates standards!
- But there are no standards for RSS!
- Are too!

and so on.

For a counterpoint, check out this blog entry:

http://www.intertwingly.net/blog/2006/01/18/Photoc asting-Hyperbole/

The whole flap is quite a learning experience if you're interested in RSS.

First of all, I don't see much security-related content on that site. Second, the issues that are raised all seem to be issues in non-AJAX web development as well.

For example, in AJAX Considered Harmful, using HTTP GETs to change state is a well-known no-no. (Google Accelerator recently broke some sites that violate this principle, but it's been known since at least HTTP 1.0 times that infrastructure would break sites that were coded incorrectly.) But XMLHttpRequest supports POSTs (and PUT, and probably all the rest). It also supports HTTPS.

As far as stealing content, that can be addressed (well enough for 95% of cases) by checking the Referer field. (I think that should work -- I wasn't able to find any documentation whether the browsers add/override that header when submitting XMLHttpRequests, like they should.) Although the random session token he suggests is a pretty good solution as well.

Bullcrap

All of RSS's 9 varieties are so similar they can easily be parsed by a single parser.

Atom has currently two varieties: 0.3 (widely used, though deprecated and denounced) and 1.0 (official IETF standard, but not very widely used yet). As with RSS's varieties, these are also not strictly compatible, though are easily parsed by the same code.

Both RSS 1.0 and RSS 2.0 support HTML natively and support XHTML through extensions.

RSS 2.0 is extensible through namespaces just like RSS 1.0 and ATOM.

RSS 1.0 is based on RDF, making it IMHO more complicated than both Atom and RSS 2.0.

Atom is much better defined than RSS.

A good (though slightly biased) overview of the differences between Atom and RSS can be found here.

Atom wins hands-down. Things are actually well specified .
I can just walk through the atom specification, implementing it as I go, and not have any questions about what is required, what type of content can be present in any one element, I don't have to look up five even less well-specified different modules just to get the basics of the feed together (and thus also don't have to worry about namespaces), what elements and attributes mean (actually, I spent a minor five minutes agonizing over what I should put in the term atribute of the category element, given that the label attribute contains the human readable version, before realizing that I was completely free in this, as the "scheme" os up to myself, and deciding to mirror how categories are named in the url on the website (which I found to be consistent with various other already existing atom 1.0 feeds that I checked)), or... well, basically any kind of question that you need to think about as you implement a new and previously unknown specification.

RSS on the other hand (any of the 9 incompatible versions)... *shudders* Those specifications don't tell me anything. I copy/paste from other feeds and heavily use the feedvalidator, but... *shakes his head*
Once all feedreaders have been updated to support Atom 1.0 completely, I'll go and pull the plug on the remaining RSS feeds, and good riddance too!

here

Unmolested version - get it while it lasts

Well, of course! Click on the Front Page link, and Voila! You are on the Atom development wiki. This is hardly an unbiased discussion.

It was intended as a rhetorical question. I was told to think "radical" after all. ;-)

Sam Ruby, IBM employee, Apache/PHP/Atom hacker, is questioning the need for middleware completely.

AJAX Considered Harmful

Sorry I just don't agree that the XHTML standard is bad. I take it that you don't consider the ESPN and Red Hat (there are many more) sites either "real-world" enough or they are "doing it wrong"?

I'm not saying that XHTML is bad. I'm saying that doing XHTML properly can be a nightmare. And no, ESPN and Red Hat and many more don't do it right; go back to Evan Goer's X-Philes list and read the criteria. Or read my by-no-means comprehensive guide to some of the things you have to do just to switch from HTML 4.01 to XHTML 1.0, and remember that these languages are element-for-element identical.

Consider the HTML 4 spec, which is syntactically difficult to decipher. After writing XHTML pages for several years now (thanks, I'm not a newbie to the web standards world) it's impossible to go back to HTML 4 and have it actually make any sense. For every open tag, you need a closing tag, except if it's horizontal line or a line break or an input or a meta tag or an image or...

And in XHTML you still don't have closing tags, you just have a closing slash on the opening tag; how is that any less confusing? And by the way, that closing slash is fine if you're doing XHTML and serving it with an XML or XHTML MIME-type, but if you serve it as text/html you're gonna give conformant SGML parsers fits (Google "SGML SHORTTAG" sometime). And there's nothing in HTML 4.01 that says you can't close your paragraphs and list items and lots of other elements... I close them because it's good coding practice no matter what version of HTML I'm using. You can do that too if you like.

It's just ugly and difficult to parse. By using XHTML, any XML parser can read a document. It's simple, if there's an open tag, close it. If there's a stand-alone tag, it better have a self-closing end. That is just one small piece of what I like about XHTML.

You've obviously never met the Yellow Screen of Death. And if you seriously believe that parsing XML is as easy as "open the tag, close the tag", I recommend you hang out on XML-related mailing lists for a while. Or just read Sam Ruby's weblog.

Insisting that if a webpage meets the XHTML Strict spec, it doesn't work in IE is just pure ignorance. Yes, typically developers have to put a little extra work into their CSS to get their pages looking as good in IE as they do in Mozilla/Firefox/Netscape/Opera/Safari/etc...

No, it's not ignorance. Go read the article by Ian Hickson I linked in my last comment; if you won't take my word, maybe you'll listen to somebody who's worked on both Mozilla and Opera and who leads the WHAT-WG. This is not about CSS bugs or quirks or rendering differences. This is about the simple fact that XHTML, according to the W3C, should be served with the MIME-type application/xhtml+xml. No version of Internet Explorer ever released on any platform anywhere is capable of dealing with that MIME-type. If you give it a page marked as application/xhtml+xml, IE will prompt you to download the page or specify another application to handle it; it literally does not know what to do with such a document.

Now, with XHTML 1.0 you are allowed to continue serving as text/html so long as you meet the HTML Compatibility Guidelines outlined in Appendix C of the XHTML 1.0 spec. Best practice here is to use some form of content negotiation to send application/xhtml+xml to user-agents which support it. However, XHTML 1.1 makes no provision of any sort for this; XHTML 1.1 is to be served as application/xhtml+xml, which means that there is no such thing as a conformant XHTML 1.1 document which will display in Intern

No, but Sam Ruby is making really good progress on Pirate, which is Python on Parrot.

2. Atom vs RSS cannot be seen as an evolution, since atom is not backward compatible. If it had been then it would have been the clear successor to RSS. This was a huge mistake of atom's creators. It should have been backwards compatible.

Atom's main goal is to have a well specified unambigious specification. The problem behind RSS is that it is ambigious - so leads to silent data loss - and it took the rather public failure at Reuters for the point to sink in. As such, it is close to impossible for a specification to be both unambigious and backwards compatible with RSS. A clean break results in a cleaner and more implementable specification, especially since we are not loaded with the baggage of previous unreversable mistakes in RSS. Notwithstanding, the "solution" to the Reuters problem now breaks RSS2.0's backward compatibility with RSS0.91.

Even the motivation behind Atom is clear:

Well, let's extend RSS into a new spec then. To keep any backwards-compatibility, we'd have to keep the top-level element as so people would think the format is actually RSS, and this would be really confusing.

Forget about backwards-compatibility. If we're not worried about backwards-compatibility, why are we bothering to keep around the old mistakes of RSS? Why not take this opportunity to fix them so that the future doesn't have to deal with all the kludges necessary to parse RSS today?

2. Atom vs RSS cannot be seen as an evolution, since atom is not backward compatible. If it had been then it would have been the clear successor to RSS. This was a huge mistake of atom's creators. It should have been backwards compatible.

Atom's main goal is to have a well specified unambigious specification. The problem behind RSS is that it is ambigious - so leads to silent data loss - and it took the rather public failure at Reuters for the point to sink in. As such, it is close to impossible for a specification to be both unambigious and backwards compatible with RSS. A clean break results in a cleaner and more implementable specification, especially since we are not loaded with the baggage of previous unreversable mistakes in RSS. Notwithstanding, the "solution" to the Reuters problem now breaks RSS2.0's backward compatibility with RSS0.91.

Even the motivation behind Atom is clear:

Well, let's extend RSS into a new spec then. To keep any backwards-compatibility, we'd have to keep the top-level element as so people would think the format is actually RSS, and this would be really confusing.

Forget about backwards-compatibility. If we're not worried about backwards-compatibility, why are we bothering to keep around the old mistakes of RSS? Why not take this opportunity to fix them so that the future doesn't have to deal with all the kludges necessary to parse RSS today?

Until Google offers an API for services like this to access it (which I doubt they ever will), any system based on GMail will be quite unstable. So, for any serious blog, this wouldn't be an option.
Since Google bought Blogger, and Blogger has its own Blogger API and is collaborating on the will-it-ever-release Atom API to eventually replace it, it seems very unlikely indeed that Google would offer a blogging API to their email service.

Of course, another benefit is that using Google's blogging API to access their blogging service is nicely in line with the TOS.

Still a cool hack, mind.

A possiblility is to try to reinvent the NNTP model over HTTP. Have big "super-nodes" which poll the originating feeds and store the result in some big database, and then allow users to pull down one big feed containing stuff from all of the sources they are interested in.

Of course, there'd have to be something in it for the super-nodes, and I suspect what would happen is that they would charge a nominal fee, or perhaps bundle it alongside some other, similar service. One example of this is LiveJournal, which currently distributes RSS and Atom feed content to any interested LiveJournal user via the "friends page" mechanism from a single database, so there's only one poll per hour (or so). All they need now is some kind of feed of the "friends view" and you have a special version of a feed distributor with some value-add: you get all of your LiveJournal friends' content in there too.

Bare RSS isn't set up for this since it can't support per-item source information, but Atom can do it and RSS can be extended through namespaces to contain the relevant info as long as it becomes popular enough that clients support it.

In fact, if this were to be done, it would also be useful to have an optional "intelligent poll" mode where the client tells the server a magic token it got on its last poll which the server can then use to give a delta feed rather than a fixed feed. This would have to be optional, since the CPU burn of it vs. just copying a static file to a socket would probably only be a win on big sites like Slashdot and BBC News Online.

In fact, it looks like the Atom guys already thought of all this. Check out AggregateFeeds, SuperAggregator and the overly-long PossibleHTTPExtensionForEfficientFeedTransfer entries in the Atom Wiki. I didn't read it all through in depth, but it looks like they're talking about the same thing I'm talking about.

A possiblility is to try to reinvent the NNTP model over HTTP. Have big "super-nodes" which poll the originating feeds and store the result in some big database, and then allow users to pull down one big feed containing stuff from all of the sources they are interested in.

Of course, there'd have to be something in it for the super-nodes, and I suspect what would happen is that they would charge a nominal fee, or perhaps bundle it alongside some other, similar service. One example of this is LiveJournal, which currently distributes RSS and Atom feed content to any interested LiveJournal user via the "friends page" mechanism from a single database, so there's only one poll per hour (or so). All they need now is some kind of feed of the "friends view" and you have a special version of a feed distributor with some value-add: you get all of your LiveJournal friends' content in there too.

Bare RSS isn't set up for this since it can't support per-item source information, but Atom can do it and RSS can be extended through namespaces to contain the relevant info as long as it becomes popular enough that clients support it.

In fact, if this were to be done, it would also be useful to have an optional "intelligent poll" mode where the client tells the server a magic token it got on its last poll which the server can then use to give a delta feed rather than a fixed feed. This would have to be optional, since the CPU burn of it vs. just copying a static file to a socket would probably only be a win on big sites like Slashdot and BBC News Online.

In fact, it looks like the Atom guys already thought of all this. Check out AggregateFeeds, SuperAggregator and the overly-long PossibleHTTPExtensionForEfficientFeedTransfer entries in the Atom Wiki. I didn't read it all through in depth, but it looks like they're talking about the same thing I'm talking about.

A possiblility is to try to reinvent the NNTP model over HTTP. Have big "super-nodes" which poll the originating feeds and store the result in some big database, and then allow users to pull down one big feed containing stuff from all of the sources they are interested in.

Of course, there'd have to be something in it for the super-nodes, and I suspect what would happen is that they would charge a nominal fee, or perhaps bundle it alongside some other, similar service. One example of this is LiveJournal, which currently distributes RSS and Atom feed content to any interested LiveJournal user via the "friends page" mechanism from a single database, so there's only one poll per hour (or so). All they need now is some kind of feed of the "friends view" and you have a special version of a feed distributor with some value-add: you get all of your LiveJournal friends' content in there too.

Bare RSS isn't set up for this since it can't support per-item source information, but Atom can do it and RSS can be extended through namespaces to contain the relevant info as long as it becomes popular enough that clients support it.

In fact, if this were to be done, it would also be useful to have an optional "intelligent poll" mode where the client tells the server a magic token it got on its last poll which the server can then use to give a delta feed rather than a fixed feed. This would have to be optional, since the CPU burn of it vs. just copying a static file to a socket would probably only be a win on big sites like Slashdot and BBC News Online.

In fact, it looks like the Atom guys already thought of all this. Check out AggregateFeeds, SuperAggregator and the overly-long PossibleHTTPExtensionForEfficientFeedTransfer entries in the Atom Wiki. I didn't read it all through in depth, but it looks like they're talking about the same thing I'm talking about.

The problem with RSS is that the spec is sufficiently vague that it is practically guaranteed that any RSS parser you write will eventually encounter an RSS feed that is valid according to the spec but cannot be correctly parsed.

That's already happened. When Reuters launched its RSS feeds two weeks ago it was valid as per the RSS2.0 specification, but every news aggregator failed to display the stock-ticker names within the feed. Silent data loss.

What is unfortunate, from an RSS perspective, is that this problem has been known for quite some time. Previous efforts to correct this problem were mired (one of the factors that lead to the Atom initiative). But it took a public failure of Reuters feeds before the RSS folk took it seriously enough to think about discussing it. So far, with the help of Mark Pilgim and aggregator authors test cases have been established for this particular scenario.

• Uses the file system (folders and files) as its content database. blojsom can support any backend storage mechanism through a specific implementation of the BlojsomFetcher interface.
• Allows you to configure the file types that blojsom treats as blog entries (defaults to .txt and .html).
• Permalinks which point to individual blog entries.
• Calendar-based (i.e. year, year/month, year/month/day) navigation of your blog.
• Configurable set of blog directories (per flavor) that get aggregated for the default or / category.
• Customizable flavors. blojsom, out of the box can generate html, rss, rss2, rdf, atom, and text flavors.
• Configurable comment and trackback support for users to leave comments and trackbacks on blog entries.
• Plugin support so that you extend the capabilities of blojsom.
• Web-based Administration for blog functionality such as editing blog properties, categories, and templates.
• Remote posting via XML-RPC and the Atom API. Support for Blogger API, MetaWeblog API, and Atom API.
• Customizable template mechanism. blojsom is very powerful in this area in that you as a developer are allowed to decide what display technology is appropriate for the requested flavor. blojsom currently offers a JSP Dispatcher and a Velocity Dispatcher and .jsp and .vm templates are provided for the HTML and RSS flavors.
  • This allows you to mix-and-match display technologies for your blog. For example, you might want to render HTML through the JSP for that flavor while you might want to render RSS through Velocity for that flavor.
  • Have another display technology youd like to use? Simply extend the BlojsomDispatcher interface and configure a mapping file so that blojsom knows how to map the template extension to the proper dispatcher. Thats it!
• Themes allow you to select a new look for your blog.
• Multi-user support with a single blojsom installation. Multi-user options specific to each user include:
  • Authorization properties for users who can post to an individual blog via XML-RPC.
  • All the blog properties such as blog directory, description, owner, default category mappings, etc.
  • Supported flavors.
  • Flavor-based plugin chains.
  • All the individual plugin configuration files are separate per-user.

It's a shame they're using RSS, as it's a good idea with a bad implementation. There are currently 9 different versions of RSS, and all of them incompatible with one another. It ought to be replaced with a better technology like Atom. However, this does look like an interesting project, nonetheless.

But I'm curious about Atom, any idea when it'll reach 1.0?

My guess is probably by the end of the year. The best place to read about its development, besides the relevent mailing lists, are Mark Pilgrim's and Sam Ruby's weblogs.

Atom has recently been submitted to the IETF for standardization.

see this not Yahoo. (Source: Sam Ruby

Actually, he's right, one version of this bug does affect Mozilla including firebird. Look at the two links on this demo page.

In the first case, the exploit works in both IE and gecko, in the second case it is IE only. Now it's a race to see which gets patched first :-)

(Sam Ruby pointed this out before me)

after the Atom standard is implemented there will be a common protocol. i think we may need to start using captchas.

The term "Echo" is an unfortunate choice of name -- it conflicts with another, new project that aims to "develop a common syntax for syndication & archiving, and an editing API." And, of these two projects, the one to which I have linked is by far the more important and likely to be far more seminal (once they have finished their work). Some of the people behind the "syndication Echo" (as distinguished from the "web app Echo" mentioned above) are very smart, e.g., Sam Ruby, Dare Obasanjo (aka "Carnage4Life" here on Slashdot) and Evan Williams, IIRC. The syndication Echo apparently grew out of the blogging API's (see bottom of page).