Modified WebRTC logo by Tsahi Levent-Levi/Flickr.

The demo bypasses a centralized server and instead makes a direct peer-to-peer connection between browsers. The key component of the demo is a set of work-in-progress standards known as WebRTC.

WebRTC is a proposed standard — currently being refined by the W3C — with the goal of providing a web-based set of tools that any device can use to share audio, video and data in real time. It’s still in the early stages, but WebRTC has the potential to supplant Skype, Flash and many device-native apps with web-based alternatives that work on any device.

The app that the Chrome and Firefox teams developed is available on Google Code and there’s a demo app available on Google app engine if you’d like to try it out for yourself. To make it work you’ll need to use either Firefox Nightly or Chrome 25 (currently in the beta channel). In Firefox, you’ll need to go to about:config and set media.peerconnection.enabled to “true.”

Mozilla has previously showed off a demo of WebRTC with it Social API and Chrome has previously used parts of WebRTC for an interactive sand sketching experiment. This latest demo relies on a new WebRTC trick known as RTCPeerConnection, which should arrive in final form in Chrome next month and Firefox around the end of May. The RTCPeerConnection support in both browsers means there’s no need for plugins and developers can rest assured their apps will “just work” across browsers. Together Chrome and Firefox account for just under 60 percent of browsers on the web.

There is of course one other major browser that’s not yet coming to the WebRTC party.

Indeed Microsoft has proposed a WebRTC competitor to the W3C, though thus far little has happened beyond the initial proposal. As it stands now neither WebRTC nor Microsoft’s competing CU-RTC-Web proposal are actual W3C standards, but work is progressing on WebRTC and, with browsers already implementing it in the wild, it stands a much better chance of becoming a standard one day.

It’s still a little early to throw out Skype. For now you’ll have to content yourself with a very cool demo and the tantalizing possibility to one day soon you might not need Skype, Facebook or any other third-party server to chat with friends around the web.

Image: Kevin Dooley/Flickr.

Transcoding video is the process of taking a user uploaded video and converting it to a video format that works on the web, typically MP4 and WebM. Consumer video services like YouTube and Vimeo handle this for you behind the scenes. But if you want to actually build the next Vimeo or YouTube you’re going to have transcode video.

Open source tools like ffmpeg simplify the video transcoding process, but require considerable server power to operate at scale. And server power is something Amazon has in spades.

Amazon’s foray into video is hardly the first cloud-powered video transcoding service — Zencoder is another popular service (and runs on Amazon servers) — but Amazon’s offering is marginally cheaper and well-integrated with the company’s other services.

The Amazon Elastic Transcoder works in conjunction with the company’s other cloud offerings like S3 file storage. You send a video from one S3 “bucket” to Transcoder, which then converts it to the formats you need and writes the resulting files to another S3 bucket.

For now the Elastic Transcoder will only output MP4 video containers with Apple-friendly H.264 video and AAC audio. The new Transcoder options in the Amazon Web Services control panel allow you to create various quality presets if, for example, you’re delivering video to both mobile and desktop clients.

As with all Amazon Web Services the new Transcoder has a pay-as-you-go pricing model with rates starting at $0.015 per minute for standard definition video (less than 720p) and $0.030 per minute for HD video. That means transcoding a 10 minute video (the max on YouTube) would cost you $.15 for SD output and $.30 for HD, which sounds cheap until you start looking at transcoding several hundred 10-minute videos a day (200 a day would set you back $60 a day for HD). Amazon’s free usage tier will get you 20 minutes of SD video or 10 minutes of HD video encoded for free each month.

Amazon’s rates are marginally cheaper than Zencoder, which charges $0.020/minute for SD and double that for HD. Zencoder does have a considerable edge when it comes to output format though, offering pretty much anything you’d need for the web, including live streaming, while, at least for now, Amazon’s offering is limited to MP4.

Image: Karin Dalziel/Flickr.

Google’s Cloud Platform tools are now available on GitHub. The move to GitHub will make it easier for developers already using GitHub to get started with Google’s various Cloud Platform offerings.

Thus far most of the repositories in Google’s GitHub account consist of code samples and projects related to offerings like App Engine, BigQuery, Compute Engine, Cloud SQL, and Cloud Storage.

The Google Open Source Blog says that most of Google Cloud Platform’s existing open source tools will be migrated to the new GitHub organization “over time.”

For now though you can get started building apps on Google Cloud Platform just by forking one of the demo repositories and tweaking the code to fit your project. Sample apps like the guestbook demos for Python and Java, along with the OAuth 2 helper apps, make a good place to start if you’ve never built anything on Google’s cloud platform before.

Image: Instructables, Altoids Advent Calendar/CC.

The holidays are here and for web nerds that means only one thing — another wave of advent tutorials is hitting the web.

It doesn’t feel much like winter right now at the Webmonkey lair, but that’s okay because we mark the start of the holiday season by the launch of 24Ways, the grand poobah of advent calendars for web nerds. 24Ways has been an annual tradition since 2005, offering 24 articles packed with new tips and tricks showcasing some of the year’s best new ideas in web development.

This year’s 24Ways kicked off with a tutorial on HTML5 Video “Bumpers” by 24Ways founder Drew McLellan. Other articles thus far include how to start a project on the right foot, how to contribute code to the community and Geri Coady’s excellent article on Color Accessibility.

While 24Ways may be the biggest name in advent tutorials, it’s not lacking for competition these days. We also recommend the Performance Calendar, which tackles the often confusing world of website optimization. There’s also Digitpaint’s advent calendar which we enjoyed last year and has already published some nice articles this year, including this look at CSS filters.

If you’re missing another favorite, the PHP Advent Calendar, fear not, it has returned, but with a new name and domain: PHP Advent is now Web Advent. The name may have changed, but Web Advent offers similarly great content, like this article on Sharing What You Know by Heather Payne, the founder of Ladies Learning Code.

Mixing old school tape loops with the BBC’s Web Audio API demo. Image: Screenshot/Webmonkey

HTML5 offers developers new ways to display and work with both audio and video on the web. The HTML5 <video> element tends to get more attention, but the HTML5 audio element is equally revolutionary, perhaps even more so thanks to the work-in-progress Web Audio API (currently in the draft stages).

Developers at the BBC recently set out to push the limits of what you can do with HTML5 <audio> and the Web Audio API. The result is a new audio playground site that recreates the sounds of the BBC Radiophonic Workshop using the Web Audio API. Note that right now only WebKit browsers support the Web Audio API. (Firefox supports the older, deprecated, Audio Data API, but plans to ship support for Web Audio in 2013.)

The BBC’s Radiophonic Workshop project is one part cool demo, one part tutorial. It’s fun to play around with, sure, but another reason behind the experiment is to document how to use <audio> and the Web Audio API. The developers also wanted to put the API through some real-world use cases, to see if there are any limitations that could be addressed before the Web Audio API becomes an official standard.

Each of the four demos has a thorough code walk-through showing exactly how it works and which elements of the Web Audio API are being used. There are a couple of dependencies, namely JQuery and Backbone.js, but most of the code is working directly with the Web Audio API.

If you’ve ever wanted to explore the Web Audio API, these demos make a great introduction to how everything works. For more background on the project, see the BBC’s Research and Development blog.

So far the code doesn’t seem to be available through the BBC’s R&D GitHub account. You can always copy and paste from the demo site, but it would be nice if it was available for easy forking and experimentation.

Google’s demo site, served entirely by Google Drive. Image: Screenshot/Webmonkey

Google has unveiled a new feature dubbed “site publishing” for the company’s Drive cloud hosting service. Drive’s new site publishing is somewhere between a full-featured static file hosting service like Amazon S3 and Dropbox’s public folders, which can make hosted files available on the web.

Google has set up a simple demo site served entirely from Google Drive to give you an idea of what’s possible with the site publishing feature. Essentially site publishing gives your public folders a URL on the web — anything you drop in that folder can then be referenced relative to the root URL. It’s unclear from the announcement how these new features fit with Google’s existing answer to Amazon S3, Google Cloud Storage.

The API behind site publishing works a lot like what you’ll find in Amazon’s S3 offering. If you use the Drive API’s files.insert method to upload a file to Drive, it will return a webViewLink attribute, something like https://googledrive.com/host/A1B2C3D4E5F6G7H8J. That ugly, but functional URL becomes the base URL for your content. So, if you uploaded a folder named images, with a file named kittens.jpg, you could access it on the web at https://googledrive.com/host/A1B2C3D4E5F6G7H8J/images/kittens.jpg

There’s one drawback though, Drive’s site publishing doesn’t appear to support custom domains, which means it works fine for assets like images, CSS or JavaScript, but unless you don’t mind serving your site from some funky URLs, it’s probably not the best choice for hosting an entire site.

There are already numerous static file hosting solutions on the web including Dropbox and Amazon’s S3, as well as whole publishing systems that use Dropbox and S3 to host files, but for those who would prefer a Google-based solution, now you have it.

For more details on the new API see the Google Apps Developer Blog and be sure to read through the Drive SDK docs. If you need help, Google is answering questions over on Stack Overflow.

Image: Amazon.

Amazon is once again jumping into the online mapping fray with a new Maps API for Android developers building apps for the Kindle Fire and Kindle Fire HD tablets. While it’s just for Android developers at the moment, several of Amazon’s other APIs have started small and grown into web-wide offerings.

Unfortunately, unlike like Amazon’s long since shuttered A9 map tools, it doesn’t appear to actually be using Amazon data. In fact, the new Maps API is really just an API wrapper around Nokia’s maps and geocoding interface, which also now powers the maps on Flickr.com.

Like Apple’s iOS 6, Foursquare and other high-profile Google Maps defectors, the Amazon Maps API seems to exist primarily as an option for those who’d like to avoid the Google Maps API. Amazon’s announcement touts the API’s “simple migration path for developers who are already using the native Google Maps API on Android,” but neglects to mention any benefits developers might gain from dropping Google’s API.

In this early beta offering Amazon’s Maps API doesn’t have any features above and beyond Google’s API. The Amazon Maps API offers most of the same features you’ll find in the Google Maps API, including street maps, satellite images and custom overlays for landmarks and points of interest, but lacks street-view imagery, terrain maps and other features found in Google’s offering.

If you’d like to give the Amazon Maps API a try in your Android app, head on over to Amazon’s new Maps API site to request access.

Apple’s new Passbook app. Image: Apple.

Apple’s recent iPhone announcement contained one tidbit of interest for web developers — Passbook.

Passbook is a new app coming in iOS 6 that collects your boarding passes, movie tickets, retail coupons, loyalty cards, and more and stores them all in one place. Checking in for a flight? Just pull up Passbook and you’re done. Ditto for redeeming coupons, getting movie tickets and so on.

What makes Passbook interesting for web developers is that on the back end there’s a REST-style API for sending updates. The API allows developers to register web services which can then automatically update content on the “pass,” as Passbook entries are known. For example, you could update a coupon or add more credit to a pass based on a transaction on your website.

Passbook communication happens through Apple’s new PassKit web service. The PassKit API offers endpoints to get the latest version of a pass, control push notifications for a pass and query for passes registered for a device.

As with all things Apple, you’ll need a developer account to build anything, but if you’d like to get some idea of how the web service end of Passbook works, check out Mattt Thompson’s passbook_rails_example. Thompson has put together a basic Rails app that shows how to work with Passbook, including how to register devices, get the latest version of a pass, get serial numbers for passes on a device and unregister a device.

For more details, head on over to GitHub.

Photo: Kevin Conboy/Flickr

A short while ago Twitter said they were going to move to JSON over XML, without much explanation other than they like JSON and not XML so much these days, etc. I’m a big believer that everyone has the right to support whatever they want when they want for whatever reason, whether they say the truth or not. Because of that belief, I take with a grain of salt every bit of support for every format and protocol. I assume that just because someone supports it today doesn’t tell you for sure that they will support it tomorrow. Though the penalty is usually pretty high for removing support for interfaces people depend on. They tend to remember it next time you ask for their trust. All that is fair game too.

So anyway, this got me thinking again about the possibility that JSON might take over from XML. What then? Should we give up all the interop we get from RSS just because it uses XML and not JSON? And it’s because of all that interop that that day will never come. A transition may happen over a long period of time, and before it’s complete there will be something after JSON. Because smart people see that, they tend to be conservative about switching just for the sake of switching. It’s why the web, which is entirely an XML application, will keep XML support everywhere for the forseeable future.

In other words, I’d bet with virtual 100 percent certainty that it’s safe to keep producing XML-based RSS feeds.

But people like JSON, there’s no denying that. And a JSONified RSS can totally co-exist with the original XML. So let’s have RSS in JSON? That’s a question that seems worth asking about, at this time.

Turns out it is a very straightforward thing to do. I of course have an RSS feed for Scripting News, the blog you’re reading right now. I wrote a script that maintains JSON and JSONP versions of the same content, automatically. When the RSS is built so are the JSON formats.

http://scripting.com/rss.json and http://scripting.com/rss.js

I learned a long time ago to embrace change. It’s why there is a RSS today that is derived from the RSS that Netscape shipped in 1999 and has features of my scriptingNews format shipped in 1997. If the world wants to go to JSON, help it get there in a way that benefits from all we learned in the evolution of RSS from 1997 through 2002. It’s stood up pretty well over the years. And there’s wide support for it, and lots of understanding of how it works. If there is to be a JSON-based syndication standard, we can cut years off the development process by simply accommodating it.

So I put together an invitation to discuss this.

http://rssjs.org/

If you find this interesting, give it some thought, and if you have something to say, write a blog post of your own, or write a comment on that page. Obviously there’s no moderation for what goes on your blog, but there will be moderation of the comments. Be aware of that. One feature of the past are personal attacks which are totally pointless and subtract from the discourse, and we should not carry that practice forward. That’s why the moderation. :-)

Otherwise, I totally look forward to hearing what people think.

Thanks…

This post first appeared on Scripting News.

Dave Winer, a former researcher at NYU and Harvard, pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software. A former contributing editor at Wired magazine, Dave won the Wired Tech Renegade award in 2001.
Follow @davewiner on Twitter.