Dave Johnson on open web technologies, social software and Java
The said it couldn't be done. They were wrong. OpenSolaris has been released under a true open source license and the project will be run as a true open source project, with outside contributors and independent distros and everything. Congrats to everybody inside and outside of Sun who helped maket his happen. This is definitely a historic day for open source.
It may also be a historic day for blogging. It's not a "normal" product launch, that's for sure. Instead of launching OpenSolaris with a media splash, press releases and a carefully crafted message, the OpenSolaris crew has taken over blogs.sun.com and let the bloggers loose. They're blogging (blogs.sun.com and opensolaris.org) and tagging (technorati, del.icio.us and flickr) and chatting (#opensolaris at freenode.net) and badging and getting the word out in their own imaginative and personal ways. I'm proud to be even a small part of that and I can't wait to get my hands on the code (of course, like everything else in my life, that'll happen right after I finish the book).
Preview version of the new NetBeans CVS Support now available!: The NetBeans team is proud to announce a preview (alpha) version of the new redesigned CVS support, an innovative approach to integration of a Version Control System (VCS) into the NetBeans Integrated Development Environment (IDE). The new module provides a simple, efficient IDE versioning workflow and intelligent support for common versioning operations.
The module is not derived from the current NetBeans VCS support, but instead is meant as a lightweight approach with less focus on architectural abstraction and much more attention to User Interface (UI) functionality.
CVS integration is the one thing that keeps pulling me back to Eclipse, so I'm really glad to hear the VCS subsystem is being re-worked (maybe 'replaced' is more accurate). Check out the screenshots, looks like good stuff. I hope better Subversion support is not far behind.
It's status time again. Quick summary: last week I spent most of my time on Roller 1.2 related issues and the Apache move. This week, I'll get back to the Roller 2.0/group blogging work.
On the Roller 1.2 front, I made some small enhancements to the Planet Roller aggregator and did some work to make the blogs.sun.com front pages a little easier to maintain. I also did a number of deployments last week to our internal blog server for testing.
Unfortunately, changing the front-pages in a Roller site is not quite as easy as changing a blog's theme. The front-pages are JSP, so you can't edit them through the Roller UI and folks who don't know Java and JSP have a hard time making changes. A number of people have suggested the idea of having a blog serve as the front pages of Roller and I think that's a great idea.
Now let's turn to Apache. Our Subversion repository space is ready at the Apache Incubator, but we're not. Since the Roller 1.2 release is coming up soon, last week we decided to keep main-line Roller development in CVS. Once the release is ready, we'll move to Subversion and branch 1.2 from there. Also: our new mailing lists are ready at Apache, but we haven't made the move yet.
Roller 2.0 work got short shrift last week, due to Roller 1.2 and related issues. Since Roller 2.0 lives in its own branch and Apache won't allow us to bring branches and history along with us (for a number of reasons, some legal), I had to do some extra work to recreate the Roller 2.0 branch in Subversion. I managed to complete that work and resume work on group blogging. I'm hoping that I can spend the rest of this week on group blogging.
That's all folks. I'm going to cover RSS and Atom in Action status in a separate post.
UPDATE: I completely forgot that we released Roller 1.1.2 last week, a minor bug fix release.
Today, I set up a new computer for the kids. I took the new 2.8Ghz Celeron box that had been serving as my Linux file-server and swapped it with the old 450Mhz P3 box that the kids were using. I was a little surprised how easy it was to make the switch. I just took the hard-drive out of the Celeron and put it in the P3 and Linux came right back up.
I set up Windows XP Home on the Celeron box and installed the important software (Warcraft and SimCity 3000) for the kids. I would have preferred something other than Windows, but we have quite an investment in games and educational software for Windows.
I also added a wireless adapter. So now, for the first time, the kids computer is on-line. I didn't setup any parental controls or filtering software and I'm not really sure what to do about "internet safety." The boys are 7 and 8 and I'm pretty sure they aren't going to go looking for trouble quite yet, but I am a little worried that Google will send them to a site of ill-repute or some horrible porn-spam message will land in their inbox. If you've got kids around that age on-line, I'd love to hear what you do to protect them from porn-spam and other internet threats.
Join us tomorrow (Tuesday, June 7th) for the first Raleigh/Cary Bloggers meetup of the month. What: An open meeting to talk about blogging, podcasting & whatever's on your mind When: Tues @ 6:30 p.m. Where: Cafe Cyclo, in Cameron Village 2020 Cameron St Raleigh, NC 27605 (map) (919) 829-3773 Who: Bloggers & people who want to blog (Podcasters welcome!) Hope to see you there!via Josh
Podcasting originated as a feature of RSS, but as the world moves to the new standard Atom format, podcasters will too. Atom can support podcasting through the element. As is the case with RSS 2.0 based podcasts, you can only have one podcast per entry. But, with Atom you can have a different representation for each language and for each content-type. For example, if you want to make a podcast available in both English and German and in both MP3 and WMV formats, you can do it by adding links like those below to the entries in your feed:
<link href=âhttp://example.com/podcasts/show001-usenglish.mpgâ hreflang=âen-USâ length=â21472922â type=âaudio/mpgâ /> <link href=âhttp://example.com/podcasts/show001-usenglish.wmvâ hreflang=âen-USâ length=â23889921â type=âaudio/wmvâ /> <link href=âhttp://example.com/podcasts/show001-german.mp3â hreflang=âde-DEâ length=â20032879â type=âaudio/mpgâ /> <link href=âhttp://example.com/podcasts/show001-german.wmvâ hreflang=âde-DEâ length=â19907766â type=âaudio/wmvâ />
Unlike the other RSS and Atom books that are hitting the shelves these days, RSS and Atom in Action is going to cover the Atom Publishing Protocol. So, I'm following the protocol development very closely. This blog entry is a summary of Atom as it stands today (based on Draft 04 released May 10, 2005). It's a follow up to my post earlier post Atom in a nutshell which explained Atom API 0.9.
Atom Publishing Protocol (a work in progress) is a new web services protocol for interacting with a blog, wiki or other type of content management system by simply sending XML over HTTP, no SOAP or XML-RPC required. Your code interacts with collections of web resources by using HTTP verbs GET, POST, PUT and DELETE as they are meant to be used. Here's how it works.
Discovering your workspaces and collections
To start out, you do an authenticated GET on a server's Atom URL to get a description of the services available to you. You get back an an Atom Services XML document that lists the workspaces and within each the collections available. A workspace could be a blog, a wiki namespace or content collection that you have access to via your username/password.
Each workspace can contain two types of collections: entries and resources. Eventually, the spec will probably allow for (at least) five types of collections: entries, categories, templates, users, and generic resources.
Here is an example of a services document XML for a blog user with access to two blogs "My Blog" and "Marketing Team Blog":
<?xml version="1.0" encoding='utf-8'?> <service xmlns="http://purl.org/atom/app#"> <workspace title="My Blog" > <collection contents="entries" title="Blog Entries" href="http://localhost:8080/roller/atom/myblog/entries" /> <collection contents="generic" title="File Uploads" href="http://localhost:8080/roller/atom/myblog/resources" /> </workspace> <workspace title="Marketing Team Blog"> <collection contents="entries" title="Blog Entries" href="http://localhost:8080/roller/atom/marketingblog/entries" /> <collection contents="generic" title="File Uploads" href="http://localhost:8080/roller/atom/marketingblog/entries" /> </workspace> </service>
Working with collections
So, a workspace is a blog and a blog contains collections of things like entries, uploaded file resources, categories, etc. All of these collections are handled the same way and respond the same way to the HTTP verbs. All support paging, so the server can return a collection in easy to digest chunks. All support query by date, so you can filter collections by start and end date.
To get a collection, do a GET on it's URI (that's the collection's 'href' as listed in the services document).
The services document specifies a URI for each collection. If you do a GET on a collection URI, you'll get back an Atom Collection XML document that lists the first X number of members in the collection. If there are more than X members, then the document will include a next URI which you can use to get the next batch of members. You can also specify an HTTP Range header to restrict a collection to only those between specific start and end dates.
Here is an example of a the collection document XML you might receive by doing a GET on the Blog Entries collection from My Blog above.
<?xml version="1.0" encoding='utf-8'?> <collection xmlns="http://purl.org/atom/app#" next="http://localhost:8080/roller/atom/myblog/entry/77088a1" > <member title="The Connells: Fun and Games" href="http://localhost:8080/roller/atom/myblog/entry/7700a0" updated="2005-04-16T23:07:08-0400" /> <member title="The Connells: Boylan Heights" href="http://localhost:8080/roller/atom/myblog/entry/7700c9" updated="2005-04-15T23:06:09-0400" /> <member title="The Connells: Gladiator" href="http://localhost:8080/roller/atom/myblog/entry/7700c8" updated="2005-04-14T14:05:31-0400" /> </collection>
Each member in a collection document has a title and a URI. To get a member of a collection, you do a GET on the member's URI. To delete it you use DELETE. To update it you use PUT. Here's an example of the entry XML you might receive by doing a GET on the first member of the Blog Entries collection example above:
<entry xmlns="http://purl.org/atom/ns#"> <title>The Connells: Fun and Games</title> <id>7700a0</id> <updated>2005-06-01T19:07:45Z</updated> <content type="html"> Let me tear down into your heart Let me take a seat and stay awhile Let me have a half of your whole Let me keep it for myself awhile </content> </entry>
To add a member to a collection, you simply POST the member to the collection's URI. If you're POSTing a new entry, send the XML for the entry (example entry XML shown below). If you're POSTing a file upload, then send the file.
That's it. Pretty simple huh?
What about authentication?
The Atom spec requires that a server support either HTTP digest authentication, which can be difficult for some bloggers to implement (depending on their ISP and web server), or CGI authentication, which can be a lot easier to implement (I believe WSSE qualifies as CGI authentication, and that's what my Atom implementation uses).
What about devices with limited HTTP support?
Some devices have crippled HTTP client capabilities. For example, some Java J2ME powered cell phones can't do an HTTP PUT or DELETE. If you can't do a PUT or a DELETE, you can use POST instead with a SOAP wrapper that specifies a Web-Method of PUT or DELETE. Atom servers are required to support SOAP POSTS and returning results in SOAP envelopes.
What about draft vs. published states for entries?
Still undecided. Some folks suggest using different collections for entries in different states (draft, approved, published, etc.). But it's more likely that a new element will be introduced in the Atom format to specify the state of an entry.
That's my summary of Atom protocol as it stands today. I think it's a great improvement over existing blog APIs in terms of features and design. And it's not very difficult to implement. I know because I'm almost done with my server and client implementations. I hope to release them shortly for review. The release will probably be a standalone release of Roller (the Atom server) and my BlogClient UI (the Atom client).
If you see some opportunities for improvement in the protocol, please join the Atom Protocol mailing list and help out. Last call for spec changes in now slated for October. And for the Atom experts out there: what did I get wrong? Leave a comment.