Torsten just posted the following announcement about the RSS Bandit support forums

Because of the amount of spam from fake user/member accounts we changed the rules related to how new members are approved to use/post to our forums.

Each new user will be approved by one of the forum administrators manually. You will have to provide a VALID e-mail address while registering. So if you don't get approved within 10 minutes, please don't try again with other/changed e-mail addresses.
We are humans and need to sleep some minutes every day

If you get access, you will receive a mail from forumadmin at rssbandit.org soon...

We were getting almost a dozen spam posts a day which made the forum RSS feed completely useless. We shut down accepting new members for a few days until Torsten figured out that we could add an approval process for new member requests.

Having to deal with approving new member requests is a hassle but a lot less than having to delete posts and member accounts created by spambots. Spammers suck. 

 

Since I've been in the process of adding support for synchronization between RSS Bandit and Newsgator Online, I've been trying to eat my own dogfood and use both applications. A ready opportunity presented itself when I travelled to Nigeria a few weeks ago and wanted to keep up with my RSS feeds. While I was in Nigeria, I was always on a dialup connection and used about four different PCs and 1 Mac. It seemed to make sense to favor a web-based RSS reader as opposed to trying to install RSS Bandit and most likely the .NET Framework on all these machines which in some cases I didn't have administrator access to anyways.

After unsuccesfully trying to use Newsgator Online I ended up settling with Bloglines instead for a number of reasons. The first being that Bloglines is a lot faster than Newsgator Online whose interface seems to move at a snail's pace over dial up. The second being that a basic feature like "Mark All Items As Read" seems to be missing from Newsgator Online. Trying to visit every feed individually to mark all its items as read became such an ordeal, I simply gave up.

I'd rather not think that I've wasted the time I've spent working on implementing synchronization between RSS Bandit and Newsgator Online since the current user experience of the latter service leaves much to be desired. I sincerely hope there are some changes in the works for the service.

 

Lots of folks I've talked to at work have had mixed feelings about the recently announced Google Talk. The feelings are usually relief and disapointment in equal portions. Relief because Google hasn't shipped yet another application that redraws the lines of what that class of application should look like (e.g. GMail and Google Maps) meaning we have to play catch up. Disappointment because we actually expect better from Google.

You can see some of these sentiments from various folks at MSN such as Mike Torres in his post Competition & Google Talk, Sanaz Ahari in her posts Google Talk review and Google Talk pt II, and Richard Chung in his post Google Talk Blows.

Of course, Microsoft employees aren't the only ones underwhelmed by Google Talk. Doing a quick search of the blogosphere for comments about Google Talk leads me to lots of bloggers expressing ambivalence about the application.

The most interesting reaction I noticed was from Robert X. Cringely who was inspired to ask Has Google Peaked? in his most recent column. In the article he not only asks whether Google's best products are already behind it but also points out that they have become experts at Fire and Motion. Below is the relevant excerpt from Robert X. Cringely's column

Google plays on its technical reputation even though, if you look closely, it isn't always deserved. Many Google products haven't been revved since they were introduced. And while some Google products are excellent, some aren't, too.

Google likes to play the Black Box game. What are they DOING in all those buildings with all those PhDs? I'm sure they are doing a lot that will change the world, but just as much that will never even be seen by the world. For the moment, though, it doesn't matter because Google can play the spoiler. They offered a gigabyte of e-mail storage, for example, at a time when they had perhaps one percent the number of e-mail users as a Hotmail or Yahoo. And by limiting the Gmail beta, they avoided the suffering of both those other companies when they, too, had to increase their storage allocations, but for tens of millions of real users.

Now Google will do something similar for chat and VoIP with Gtalk, pushing the others toward an interoperability that undermines the hold each company thinks it has on its users.

In my original post about Google Talk I mentioned that using Jabber/XMPP was an attempt at a disruptive move by Google. Of course, it is only disruptive if its competitors like AOL, MSN and Yahoo! react by breaking down the walls of the walled gardens they have created in their various IM products.

I find it interesting that instead of trying to push the envelope with regards to the user experience in instant messaging, Google chose to 'punk' its competitors instead. I guess we'll just have to see how MSN, Yahoo & AOL end up reacting. 

 

Sean Lyndersay has posted about an update to the Simple List Extensions specification. The update fixes some of the issues that were pointed out by members of the RSS community such as the problem pointed out in Phil Ringnalda's post MS Embraces RSS because RSS elements were being reused outside their original context. The cf:listinfo element now has the following structure

<cf:listinfo>
  <cf:sort
     ns="namespace"
     element="element"
     data-type="date|text|number"  
     label="User-readable name for the sort field"
     default="yes|no" />

  <cf:group
     ns="namespace"
     element="element"
     label="User-readable name for the grouping" />

</cf:listinfo>

This is a lot better than the original spec* which instead of naming the element being sorted on using attributes of  the cf:sort element actually included it as a child element instead. The only problem I have with the spec is that I don't see where it states the date format that is expected to be used if the data type is date. I guess this was problematic since different syndication formats use different date formats. RSS 2.0 uses the RFC 822 format, Atom 1.0 uses the RFC 3339 format while Dublin Core [which is what RSS 1.0 dates typically are] uses the format from the W3C Note on Date and Time formats. So an extension element really can't define what the date format will be in the feed it is embedded in since it may be embedded in an RSS or Atom feed.

That is a potential gotcha for implementers of this spec. I think I'll pass at implementing support for the Simple List Extensions spec in RSS Bandit this time around since my plate is full for this release. I'll add it to the list of features that will show up in the following release [tentatively codenamed Jubilee].

* I would have linked to the spec but as usual MSDN has broken permalinks such as http://msdn.microsoft.com/longhorn/understanding/rss/simplefeedextensions/ . Someone really needs to force everybody that works there to read Cool URIs don't change.

 

David Card of Jupiter Research has a blog post entitled Pre-emptive IM Strike from MSN where he describes one of the reasons I love working at MSN

Finally, MSN wants to remind everyone that it's got six years of experience in this stuff -- hear that, Sergey? -- and is sticking to its promise of thrice-yearly upgrades, so watch for more goodies in November.

The upgrades are all fine, but I was actually more impressed by Irving's crisp articulation of the IM Big Picture. MSN is trying to move the conversation away from IM (defined as "real-time text messaging," how dull) to "contacts." I think they downplay presence management, but that's okay, presence sounds too much like AOL-friendly talk. As does Buddy Lists, but I can't break the habit.

What's critical about IM isn't real-time text messaging but the Buddy List as a communications/presence management hub.(Link is ancient history for geek/vision cred.) You manage your buddies and buddy groups and their relationships to you (and each other), shifting those according to what persona you're inhabiting (work, home, fun, shopping, etc.) and what communications are available to you or you want to make available to them. Then broadcast that selectively. The company that can teach consumers how to do this, and own that management tool is in a very powerful position. The portals will be duking it out with the mobile carriers for this, I suspect.

MSN's vision is pretty parallel to the one above. Irving claims Microsoft has an "ABCH" -- Address Book Clearing House -- that is a repository for all those contacts, relationships and permissions that come from Messenger and Hotmail. You can imagine how powerful that might be -- we're not just talking "gleams" and sharing playlists here -- and how much grief Microsoft will get for playing Big Brother.

Anyway, MSN gets it.

Besides the fact that I'm one of the program managers for ABCH and thus it's kind of cool to get a shout out from our VP, there are some other things about this excerpt that have me smiling. When I first came to MSN I thought I'd have to beat people over the head with the message that Social Software is the Platform of the Future but I didn't have to because everybody gets it. Everyone I've talked to from vice presidents and general managers to developers and testers working directly on individual features has their mind wrapped around our social software vision. It's really simple, the #1 goal of social software should be around improving the ways I communicate and interact with the people I know and a secondary goal is giving me avenues to communicate and interact with people I don't. It's really that simple.

We definitely have some interesting stuff coming down the road in the next couple of months. I can only hope our users have as much fun using our software as we had building it.

On an unrelated note, I have updated the track of the week from my high school days on my space. Just click on the play button on the Windows Media player module to hear this week's track. Listening to some of this stuff I can't help thinking, "I could have been a contender". :)

 

As I mentioned a few weeks ago, we plan to ship an alpha of the next version of RSS Bandit [codenamed Nightcrawler] next week. So far we've been making some progress towards that goal. I checked in the changes to enable marking items as read or flagging them from the newspaper view and I've already found it to be quite useful. A screenshot is below

I've also been hard at work implementing support for synchronization with Newsgator Online via the Newsgator API. It's been more difficult than I expected but I'm sure our users will love being able to move between a web based aggregator or a desktop aggregator as the need arises but have their subscriptions and items they've read stay consistent between both places. Ideally the experience should be the same as moving back and forth between Web mail (e.g. Hotmail) and a desktop mail reader (e.g. Outlook Express).

I've also completed our support for Atom 1.0 and tested against a number of known Atom 1.0 feeds in the wild.

Torsten is working on the new subscription wizard and the podcasting support which should be finally checked in by next week. 

By the way Torsten has started an RSS Bandit new logo design contest and we'd appreciate your comments. It seems a lot of our users who use RSS Bandit from their place of work feel our current smily face icon and logo are unprofessional. I don't mind changing our application icon but would probably like to keep the smily bandit in the logo.

So it looks like we are on track for having the installer for the Nightcrawler alpha available next week. Hope you guys like the new features.

 

Today I stumbled on the post "Sign up for Gmail"on the Google blog and I was stunned by the following excerpt

For the last 16 months, a lot of people have been asking us how they can sign up for Gmail, and today we're happy to be able to say, "Just go to gmail.com." From there, you can get an invitation code sent to your mobile phone, and with this code, you can create a Gmail account. Once you have Gmail, you can try out our brand new IM and voice service, Google Talk.

Why use mobile phones? It's a way to help us verify that an account is being created by a real person, and that one person isn't creating thousands of accounts. We want to keep our system as spam-free as possible, and making sure accounts are used by real people is one way to do that.

The privacy implications of having a company collect people's verified mobile phone numbers just for free email accounts boggles the mind. It is common knowledge that web surfers often give websites information they consider private thus I'm sure lots of people will take them up on their offer.  Looking at the GMail SMS mail sign up page it boldly states they plan to store the phone number indefinitely and then points to a privacy policy that doesn't say anything about what they plan to do with our phone numbers. Is their legal team asleep at the wheel or something?

I guess once they ship whatever mobile services that emerge from their purchase of Dodgeball and Android, they'll have a ready pool of phone numbers to launch the service with. That's just genius. Almost evil genius.

 

There were two instant messaging releases shipped yesterday from two of the major online players.

1. Google Talk Beta: Google has finally shipped an instant messaging application as we all expected. You can get the scoop from Joe Beda's post Welcome To Google Talk. It seems Joe is one of the folks at Google who helped ship this. From his post we learn they provide

   • Instant messaging server based on the XMPP/Jabber protocol.  This is an IETF approved protocol.  Check out www.xmpp.org for more info.
   • Out of the box support for many third party clients.  Choose iChat, Gaim, Trillian or a host of others.  We support them from day one.
   • Our own client available for download from talk.google.com.  We've concentrated on a simple to use and clean interface.  We've tried to strip IM down to its essence.
   • Support for voice calls between clients that just work.  We've worked hard to support all sorts of network topologies.  We are also using first class industry leading audio codecs.
   • A commitment to openness moving forward.  Choose your platform (Window, Mac, Linux, etc), choose your client (ours or others) and choose your service provider (we are commited to federation).  We want to make IM as open as the web or email.

2. MSN Messenger 7.5: MSN shipped to its instant messaging client yesterday. You can get the scoop in Leah Pearlman's post MSN Messenger 7.5 - I can't believe It's Not Beta. From her post we learn that some of the new features are

   • Dynamic Backgrounds: Backgrounds that subtly animate in cool ways.

   • Voice Clip: Press and hold the Voice Clip button (or F2) and record up to 15 seconds of your voice or anything. When you release, it goes to your buddies just like an IM, and they can hear it instantly upon receipt.
   • Freaking Awesome Audio Quality Improvements: Yes, that’s the technical name. Our new audio technology makes free Voice (Voip) calls super-clear. Mostly thanks to much improved echo-cancellation. It’s now just like using a phone except: "Look ma! No hands!"
   • Patching: Due to the plethora of features in the Messenger client the download size has grown. In the future, instead of having to download the entire client each time an particular release is updated, we can download a small patch, on the order of 100K on to the user’s machine instead.

Google's entrance into the instant messaging landscape is interesting although unsurprising. As usual Google has entered the space with a disruptive move but instead of the move being the feature set of its IM client it is by not treating their IM network as a walled garden as AOL, MSN and Yahoo! have done. People aren't restricted to the Google Talk client and anyone can write a client application to connect people within their network. I'm not sure this is a smart move but it definitely is a disruptive one.

 

Last week I had lunch with Joshua Allen and mentioned that I was planning to write a blog post about the game changing effect of some entity adding generally accessible offline support to the AJAX capabilities of traditional web browsers. It seems Jason Kottke has beaten me to writing this with his post  GoogleOS? YahooOS? MozillaOS? WebOS? , he even has a roll call of the usual suspects who might build this and why.

He writes

So who's going to build these WebOS applications? Hopefully anyone with XHTML/JavaScript/CSS skills, but that depends on how open the platform is. And that depends on whose platform it is. Right now, there are five organizations who are or could be moving in this direction:

• Google. If Google is not thinking in terms of the above, I will eat danah's furriest hat. They've already shifted the focus of Google Desktop with the addition of Sidebar and changing the name of the application (it used to be called Google Desktop Search...and the tagline changed from "Search your own computer" to the more general "Info when you want it, right on your desktop"). To do it properly, I think they need their own browser (with bundled Web server, of course) and they need to start writing their applications to work on OS X and Linux (Google is still a Windows company)[4]. Many of the moves they've made in the last two years have been to outflank Microsoft, and if they don't use Google Desktop's "insert local code into remote sites" trick to make whatever OS comes with people's computers increasingly irrelevant, they're stupid, stupid, stupid. Baby step: make Gmail readable offline.
• Yahoo. I'm pretty sure Yahoo is thinking in these terms as well. That's why they bought Konfabulator: desktop presence. And Yahoo has tons of content and apps that that would like to offer on a WebOS-like platform: mail, IM, news, Yahoo360, etc. Challenge for Yahoo: widgets aren't enough...many of these applications are going to need to run in Web browsers. Advantages: Yahoo seems to be more aggressive in opening up APIs than Google...chances are if Yahoo develops a WebOS platform, we'll all get to play.
• Microsoft. They're going to build a WebOS right into their operating system...it's likely that with Vista, you sometimes won't be able to tell when you're using desktop applications or when you're at msn.com. They'll never develop anything for OS X or for Linux (or for browsers other than IE), so its impact will be limited. (Well, limited to most of the personal computers in the world, but still.)
• Apple. Apple has all the makings of a WebOS system right now. They've got the browser, a Web server that's installed on every machine with OS X, Dashboard, iTMS, .Mac, Spotlight, etc. All they're missing is the applications (aside from the Dashboard widgets). But like Microsoft, it's unlikely that they'll write anything for Windows or Linux, although if OS X is going to run on cheapo Intel boxes, their market share may be heading in a positive direction soon.
• The Mozilla Foundation. This is the most unlikely option, but also the most interesting one. If Mozilla could leverage the rapidly increasing user base of Firefox and start bundling a small Web server with it, then you've got the beginnings of a WebOS that's open source and for which anyone, including Microsoft, Google, Yahoo, and anyone with JavaScript chops, could write applications. To market it, they could refer to the whole shebang as a new kind of Web browser, something that sets it apart from IE, a true "next generation" browser capable of running applications no matter where you are or what computer (or portable device) you're using.

So yeah, that's the idea of the WebOS (as I see it developing) in a gigantic nutshell.

I disagree with some of his post; I think desktop web servers are a bad idea and also that the claims of the end of Microsoft's operating system dominance are premature. He is also mistaken about MSN not building stuff for browsers other than IE. Of course, overestimating Microsoft's stupidity is a common trait among web developer types.

However the rest of his post does jibe with a lot of thinking I did while on vacation in Nigeria. I'd suggest that anyone interested in current and future trends in web application development should check it out.

 

 

My post on Why I Prefer SOA to REST got some interesting commentary yesterday that indicates that I probably should clarify what I was talking about. The most interesting feedback actually came from email from some evangelists at Microsoft who had a bunch of criticisms from the fact that I dared to use Wikipedia as a definitive reference to pointing out that SOA is a meaningless buzzword. So I'll try this again without using links to Wikipedia or the acronym "SOA".

My day job is designing services that will be used both within MSN by a number of internal properties (Hotmail, MSN Spaces, MSN Messenger, and a lot more) as well as figuring out what our external web services story will be for interacting with MSN Spaces. This means I straddle the fence of dealing with building distributed applications in a primarily homogenous intranet environment and the heteregenous World Wide Web. When I talk about "distributed applications" I mean both scenarios not just Web service development or enterprise service development.

Now let's talk about REST. In Chapter 5 of Roy Fieldings Dissertation where he introduces the concept of Representational State Transfer (REST) architectural style he writes

5.1.5 Uniform Interface

The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6). By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. Implementations are decoupled from the services they provide, which encourages independent evolvability. The trade-off, though, is that a uniform interface degrades efficiency, since information is transferred in a standardized form rather than one which is specific to an application's needs. The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. These constraints will be discussed in Section 5.2.
...
5.2.1.1 Resources and Resource Identifiers

The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.

The REST architecture describes how a large interlinked web of hypermedia works which is what the World Wide Web is. It describes a way to build a certain class of distributed application, specifically one where you are primarily interested in manipulating linked representations of resources where the representations are hypermedia.

On to service orientation. The canon of service orientation are the four tennets taken from the article A Guide to Developing and Running Connected Systems with Indigo by Don Box where he wrote

In Indigo, a service is simply a program that one interacts with via message exchanges. A set of deployed services is a system. Individual services are built to lastthe availability and stability of a given service is critical. The aggregate system of services is built to allow for changethe system must adapt to the presence of new services that appear a long time after the original services and clients have been deployed, and these must not break functionality.

Service-oriented development is based on the four fundamental tenets that follow:

Boundaries are explicit A service-oriented application often consists of services that are spread over large geographical distances, multiple trust authorities, and distinct execution environments...Object-oriented programs tend to be deployed as a unit...Service-oriented development departs from object-orientation by assuming that atomic deployment of an application is the exception, not the rule. While individual services are almost always deployed atomically, the aggregate deployment state of the overall system/application rarely stands still.

Services are autonomous Service-orientation mirrors the real world in that it does not assume the presence of an omniscient or omnipotent oracle that has awareness and control over all parts of a running system.

Services share schema and contract, not class Object-oriented programming encourages developers to create new abstractions in the form of classes...Services do not deal in types or classes per se; rather, only with machine readable and verifiable descriptions of the legal "ins and outs" the service supports. The emphasis on machine verifiability and validation is important given the inherently distributed nature of how a service-oriented application is developed and deployed.

Service compatibility is determined based on policy Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy.

One thing I want to point out at this point is that neither REST nor service orientation are technologies. They are approaches to building distributed applications. However there are technologies typically associated with both approaches, REST has Plain Old XML over HTTP (POX/HTTP) and service orientation has SOAP.

My point from yesterday was that as far as approaches go, I prefer to think of building distributed applications from a service oriented perspective than from a REST perspective. This is completely different from endorsing SOAP over using POX/HTTP as the technology for building distributed applications. That is a discussion for another day.