Recently I was chatting with Steve Rider on the Start.com team about the various gotchas awaiting them as they continue to improve the RSS aggregator at http://www.start.com/1/. I mentioned issues like feeds which don't use title's like Dave Winer's and HTML showing up in titles.

I thought I knew all the major RSS gotchas and RSS Bandit handled them pretty well. However I recently got two separate bug reports from users of WordPress about RSS Bandit's inability to handle extension elements in their feed. The first complaint was about Kevin Devin's RSS feed which couldn't be read at all. A similar complaint was made by Jason Bock who was helpful enough to debug the problem himself and provide an answer in his post RSS Bandit problem fixed where he wrote

I can't believe what it took to fix my feed such that Rss Bandit could process it.

I'm just dumbfounded.

Basically, this is the way it looked:

						<rss xmlns:blog="urn:blog">
   <blog:info directory="JB\Blog" />
   <channel>
      <!--  Channel stuff goes here... -->
   </channel>
</rss>

				

This is what I did to fix it:

						<rss xmlns:blog="urn:blog">
   <channel>
      <!--  Channel stuff goes here... -->
   </channel>
   <blog:info directory="JB\Blog" />
</rss>

				

After debugging the Rss Bandit code base, I found out what the problem was. Rss Bandit reads the file using an XmlReader. Basically, it goes through the elements sequentially, and since the next node after <rss> wasn't <channel>, it couldn't find any information in the feed, and that's what was causing the choke. Moving <blog:info> to the end of the document solved it.

The assumption I made when developing the RSS parser in RSS Bandit was that the top level rss element would have a channel element as its first child element. I handle extension elements if they appear as children of the channel or item element since these seem logical but never thought anyone would apply an extension to the rss element. I took a look at what the RSS 2.0 specification says about where extension elements can appear and it seems my assumption was wrong since it states

RSS originated in 1999, and has strived to be a simple, easy to understand format, with relatively modest goals. After it became a popular format, developers wanted to extend it using modules defined in namespaces, as specified by the W3C.

RSS 2.0 adds that capability, following a simple rule. A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.

Since there is no explicit restriction of where extension elements can appear it looks like I'll have to make changes to be able to expect extension elements anywhere in the feed.

My apologies to the folks who've had problems reading feeds because of this oversight on my part. I'll fix the issue today and refresh the installer later this week.

 


 

I've seen a number of responses to my recent post, SOA, AJAX and REST: The Software Industry Devolves into the Fashion Industry, about the rebranding of existing techniques for building websites which used to be called DHTML or Remote Scripting to AJAX. I've found the most interesting responses to be the ones that point out why this technique isn't seeing mainstream usage in designing websites.

Scott Isaacs has a post entitled AJAX or as I like to call it, DHTML where he writes

As Adam Bosworth explained on Dare's blog, we built Ajax-like web applications back in 1997 during and after shipping IE4 (I drove the design of DHTML and worked closely with the W3C during this period).  At that time xmlhttp (or xml for that matter) did not exist. Instead, structured data was passed back and forth encapsulated in Javascript via hidden IFrames.  This experimental work helped prove the need for a structured, standardized approach for managing and transporting data.

Over the years, quite a few web applications have been built using similar approaches - many are Intranet applications and one of the best was Outlook Web Access. However, very few main-stream web-sites appeared. I believe this was due to a number of factors - the largest being that the typical web user-experience falls apart when you start building web-based applications.  The user-interface issues revolve mostly around history and refresh. (For example - In GMail, navigate around your inbox and either refresh the page or use the back button. In Spaces (IE Users), expand and view comments and hit the back button.  I am willing to wager that what happens is not what you really want).  The problem lies in we are building rich applications in an immature application environment. We are essentially attempting to morph the current state of the browser from a dynamic form package to a rich application platform.

I have noticed these problems in various Javascript based websites and it definitely is true that complex Javascript navigation is incompatible with the traditional navigation paradigm of the Web browser. Shelley Powers looks at the problems with Javascript based websites from another angle in her post The Importance of Degrading Gracefully where she writes

Compatibility issues aside, other problems started to pop up in regards to DHTML. Screen readers for the blind disabled JavaScript, and still do as far as I know (I haven’t tried a screen reader lately). In addition, security problems, as well as pop-up ads, have forced many people to turn off JavaScript–and keep it off.

(Search engines also have problems with DHTML based linking systems.)

The end result of all these issues–compatibility, accessibility, and security–is a fundamental rule of web page design: whatever technology you use to build a web page has to degrade, gracefully. What does degrade, gracefully, mean? It means that a technology such as Javascript or DHTML cannot be used for critical functionality; not unless there’s an easy to access alternative.
...
Whatever holds for DHTML also holds for Ajax. Some of the applications that have been identified as Ajax-enabled are flickr and Google’s suite of project apps. To test how well both degrade, I turned off my JavaScript to see how they do.
...
Google’s gmail, on the other hand, did degrade, but did not do so gracefully. If you turn off JavaScript and access the gmail page, you’ll get a plain, rather ugly page that makes a statement that the primary gmail page requires JavaScript, either turn this on, get a JS enabled browser, or go to the plain HTML version.

Even when you’re in the plain HTML version, a prominent line at the top keeps stating how much better gmail is with a Javascript enabled browser. In short, Google’s gmail degrades, by providing a plain HTML alternative, but it didn’t do so gracefully; not unless you call rubbing the customer’s nose in their lack of JS capability “graceful”.

You don’t even get this message with Google Suggest; it just doesn’t work (but you can still use it like a regular search page). As for Google Maps? Not a chance–it is a pure DHTML page, completely dependent on JavaScript. However, Mapquest still works, and works just as well with JS as without.

(Bloglines also doesn’t degrade gracefully — the subscription is based on a JavaScript enabled tree. Wordpress, and hence Wordform, does degrade gracefully.)

If we’re going to get excited about new uses of existing technology, such as those that make up the concept of Ajax, then we should keep in mind the rule of degrading gracefully: Flickr is an example of a company that understands the principle of degrading gracefully; Google is an example of a company, that doesn’t.

Update: As Doug mentions in comments, flickr is dependent on Flash. If Flash is not installed, it does not degrade gracefully.

I do remember being surprised that I had to add "http://*.google.com" to my trusted sites list to get Google Maps to work. Of course, none of the above observations is new but given that we are seeing a renaissance of interest in using Javascript for building websites, it seems like a good idea for a similar return of the arguments discussing the cons of this approach as well.


 

Categories: Technology

While at ETech I got to spend about half an hour chatting with Steve Gillmor about what he's called "the attention problem" which isn't the same thing as the attention.xml specification. The attention problem is the problem that faces every power users of XML syndication clients such as RSS Bandit or Bloglines. It is so easy to subscribe to various feeds that eventually readers get overwhelmed by the flood of information hitting their aggregator's inbox. Some have used the analogy "drinking from a firehose" to describe this phenomenon.

This problem affects me as well which is the impetus for a number of features in the most recent release of RSS Bandit such as newspaper views which allow one to view all the unread posts in a feed in single pane, adding more sortable columns such as author and comment count to the list view, and skim mode ('mark all items as read on exiting a feed or category'). However the core assumption behind all these features is that the user is reading every entry.

Ideally a user should be able to tell a client, "Here are the sites I'm interested in, here are the topics I'm interested in, and now only show me stuff I'd find interesting or important". This is the next frontier of features for RSS/ATOM aggregators and an area I plan to invest a significant amount of time in for the next version of RSS Bandit.

In my post Some Opinions on the Attention.xml Specification I faulted the attention.xml specification because it doesn't seem to solve the problems it sets out to tackle and some of the data in the format is unrealistic for applications to collect. After talking to Steve Gillmor I realize another reason I didn't like the attention.xml spec; it ignores all the hard problems and assumes they've been solved. Figuring out what data or what algorithms are useful for determining what items are relevant to a user is hard. Using said data to suggest new items to the user is hard. Coming up with an XML format for describing an arbitrary set of data that could be collected by an RSS aggregator is easy.

There are a number of different approaches I plan to explore over the next few months in various alphas of the Nightcrawler release of RSS Bandit.  My ideas have run the gamut from using Bayesian filtering to using the Technorati link cosmos feature for weighting posts [in which case I'd need batch methods which is something I briefly discussed with Kevin Marks at Etech last week]. There is also weighting by author that needs to be considered, for example I read everything written by Sam Ruby and Don Box. Another example is a topic that may be mundane (e.g. what I had for lunch) and something I'd never read if published by a stranger but would be of interest to me if posted by a close friend or family member.

We will definitely need a richer extensibility model so I can try out different approaches [and perhaps others can as well] before the final release. Looks like I have yet another spring and summer spent indoors hacking on RSS Bandit to look forward to. :)


 

I woke up this morning to find an interesting bit of Web history posted in a comment in response my post SOA, AJAX and REST: The Software Industry Devolves into the Fashion Industry by Adam Bosworth. He wrote

I actually agree with the post and I could care less what it is called (Ajax or DHTML or ..) but I thought I'd correct a couple of historical points. We (I led the IE MSFT 4.0 team which shipped in the fall of 97) called it DHTML because we introduced the read and writable DOM so that Ecmascript could dynamically modify the page to react to fine grained user actions and asynchronous events. That really was new and inventing this and the term occured simultaneously. Scott Isaac drove this work and worked tirelessly to get it into the W3C. We (MSFT) had a sneak preview for many developers in the fall of 96 actually showing things like pages expanding and collapsing in the gmail style and Tetris running using Javascript and DHTML in the page. Before then, javascript could hide/unhide items and react to some coarse events, but that was about it. We added the XMLHTTPRequest object (Chris Lovett actually did this) in IE 5.0 when we wrote the auction demo to show how XML could be used with IE to build a new interactive client. If there was a pioneer for Ajax, I'd argue that the auction demo was it.

I am surprised by how familiar I am with some of the people he mentions. Chris Lovett is currently an architect on the XML team at Microsoft and was the person who gave me the Extreme XML column on MSDN when I was still fresh out of college in my few months at Microsoft. Scott Isaacs is an architect on the MSN Spaces team who I've been in a few design meetings with so far. Cool.

I also see that Adam is back posting to his blog with his post Tensions on the Web. He mentions our conversation at ETech, specifically

I haven't posted for quite a while because my last posts caused unfair attacks on Google by twisting the words I'd used in my posts and attributing my posts to Google. I want to be really clear about something. The opinions I express in this Blog are my own. They have nothing to do with Google's opinions. Google only asks that I not leak information about future products. Period. But despite that, recent blog posts of mine were used to attack Google and this upset me deeply. Much to my surprise, Dare Obasanjo came up to me and told me, after some fairly vitriolic complaining from me to him about this earlier state of affairs, that he wished I'd continue to post. I thought about this over the weekend and decided that to some degree, you have to take your chances in this environment rather than just hide when you don't like the behavior and that perhaps I was being over sensitive anyway. There are too many interesting things going on right now anyway.

Adam's blog postings have been somewhat inspirational to me and part of the reason I decided to move to MSN (in fact, I'd considered leaving Microsoft). They also led to the most popular entry in my blog, Social Software is the Platform of the Future. It's good to see that he's back to sharing his ideas with us all.

Welcome back to the blogosphere, Adam.


 

Categories: Ramblings

Ever since the article Ajax: A New Approach to Web Applications unleashed itself on the Web I've seen the cacophony of hype surrounding Asynchronous JavaScript + XML (aka AJAX reach thunderous levels. The introduction to the essay already should make one wary about the article, it begins

Ajax isnt a technology. Its really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

So AJAX is using Javascript and XML with the old new twist being that one communicates with a server using Microsoft's proprietary XmlHttpRequest object. AJAX joins SOA in ignominy as yet another buzzword created by renaming existing technologies which becomes a way for some vendors to sell more products without doing anything new. I agree with Ian Hixie's rant Call an apple an apple where he wrote

Several years ago, HTML was invented, and a few years later, JavaScript (then LiveScript, later officially named ECMAScript) and the DOM were invented, and later CSS. After people had been happily using those technologies for a while, people decided to call the combination of HTML, scripting and CSS by a new name: DHTML. DHTML wasn't a new technology it was just a new label for what people were already doing.

Several years ago, HTTP was invented, and the Web came to be. HTTP was designed so that it could be used for several related tasks, including:

  • Obtaining a representation of a resource from a remote host using that resource's identifier (GET requests).
  • Executing a procedure call on a remote host using a structured set of arguments (POST requests).
  • Uploading a resource to a remote host (PUT requests).
  • Deleting a resource from a remote host (DELETE requests).

People used this for many years, and then suddenly XML-RPC and SOAP were invented. XML-RPC and SOAP are complicated ways of executing remote procedure calls on remote hosts using a structured set of arguments, all performed over HTTP.

Of course you'll notice HTTP can already do that on its own, it didn't need a new language. Other people noticed this too, but instead of saying "hey everyone, HTTP already does all this, just use HTTP", they said, "hey everyone, you should use REST!". REST is just a name that was coined for the kind of architecture on which HTTP is based, and, on the Web, simply refers to using HTTP requests.

Several years ago, Microsoft invented XMLHttpRequest. People used it, along with JavaScript and XML. Google famously used it in some of their Web pages, for instance GMail. All was well, another day saved... then someone invented a new name for it: Ajax.
...
So I have a request: could people please stop making up new names for existing technologies? Just call things by their real name! If the real name is too long (the name Ajax was apparently coined because "HTTP+XML+HTML+XMLHttpRequest+JavaScript+CSS" was too long) then just mention the important bits. For example, instead of REST, just "HTTP"; instead of DHTML just "HTML and script", and instead of Ajax, "XML and script".

What I find particularly disappointing about the AJAX hype is that it has little to do with the technology and more to do with the quality of developers building apps at Google. If Google builds their next UI without the use of XML but only Javascript and HTML will we be inundiated with hype about the new JUDO approach (Javascript and Unspecified DOm methods) because it uses proprietary DOM extensions not in the W3C standard?

The software industry perplexes me. One minute people are complaining about standards compliance in various websites and browsers but the next minute Google ships websites built on proprietary Microsoft APIs and it births a new buzzword. I doubt that even the fashion industry is this fickle and inconsistent.

Postscript: I wasn't motivated to post about this topic until I saw the comments to the post Outlook Web Access should be noted as AJAX pioneer  by Robert Scoble. It seems some people felt that Outlook Web Access did not live up to the spirit of AJAX. Considering that the distinguishing characteristic of the AJAX buzzword is using XmlHttpRequest and Outlook Web Access is the reason it exists (the first version was written by the Exchange team) I find this highly disingenious. Others have pointed this out as well, such as Robert Sayre in his post Ever Wonder Why It's Called "XMLHTTPRequest"?


 

Categories: XML

Last night, we put the finishing touches on an upgrade to the server-side of MSN Messenger. The maximum size of a buddy list has been increased from 150 to 300. Enjoy.
 

Categories: MSN

March 21, 2005
@ 12:02 PM

TDavid has a post critical of MSN Spaces where he writes  I think it's about time for another MSN Spaces update.

I'm starting to lose interest in MSN Spaces as a blogging tool.

Some of the future features that have been hinted at like the ability to host a spaces at our own domain like blogger does need to come to fruition to revitalize my interest in this service. I purchased a domain for this very purpose months ago and they sit, collectin dust.

Not just me though, I don't hear many others talking about MSN Spaces any more either. I know the target audience isn't regular bloggers, but just people who want to have a journal, but if Microsoft really wants MSN Spaces to compete with blogger then they need to add the ability to run off their own domain and open up the template customization a lot more.

Otherwise this will become -- maybe it already is -- just a glorified diary for sharing notes, pictures and music playlists with family and friends.

I'll let Mike talk about upcoming features, site updates and the like. There is one thing, I would like to address though. If people view MSN Spaces as a place for people to share their words, music and images with their friends and family then it would be fulfilling our goals for the site and I'd view it as an unbridled success. In my post entitled Why MSN Spaces and not MSN Blogs? I wrote

As to why they are called "spaces" as opposed to "blogs" it is because we believe there is more to sharing one's experiences online than your online journal. People want to share their thoughts, their favorite music, their favorite books, pictures of their loved ones and so on. It isn't just  posting your thoughts and experiences in the reverse chronological order which is what typically defines a "weblog". It's supposed to be a person's personal space online which was the original vision of personal publishing on the Web which spawned the personal homepage revolution a couple of years ago. Weblogs are the next iteration of that vision and we expect MSN Spaces to be the refinement of that iteration.

MSN Spaces is designed to allow people to create textual and visual diaries of their lives to share with others. We aren't the only one's that believe this as is evidenced by competing services such as Yahoo! 360° which has borrowed a leaf or two from our book. I'm curious as to what other goals a weblogging service could have?


 

Categories: MSN

A few days ago I wrote a post entitled Bringing Affirmative Action to Blogging where I jokingly asked whether we would need a blaggercon conference for black bloggers. Less than a week later I found out there was a blogging while black panel at the SXSW conference via Nancy White's blog. The blogged transcript of the panel interesting.

Another thing I found interesting was the ratio of men to women at the panel which Nancy White put at 28:80 (35%) which is quite impressive for a technology conference. This compares unfavorably with the O'Reilly Emerging Technology Conference which a number of women in technology have criticized for being heavily male dominated. These posts include SXSW, why i attended and marginalized populations by Danah Boyd, why sxsw by Liz Lawley and Number 9 Number 9 Number 9 by Shelley Powers. These posts mainly point out that given that both ETech and SXSW were being held at the same time, it seems many women chose the latter over the former. Funny enough, while I did get the feeling that there were way too many white guys at ETech even for a technology conference I wasn't thinking "where are the women?" but instead "where are all the Indian men?". I guess that reveals something about me.

Speaking of conferences,  I did find Dave Winer's post on two-level communities to be quite interesting. Specifically

Last week there were two conferences that I didn't go to but followed through the Web. I could have gone to either of them in person, if I had been willing to pay their fees, and been willing to be in the audience or the hallways, at all times. In other words, I would have to accept my place as a second-level person, an outsider, in the presence of insiders...I remember well what it was like going to Esther's conferences in the 80s, when the insiders all had someone to eat with, and I was paying thousands of dollars for the priviledge of eating by myself because I didn't know anyone.

There's also a post in a similar vein from a participant at SXSW entitled How it feels to be an outsider which goes into more detail about what it feels like to be an outsider at one of these conferences.

Personally I got a lot of value out of ETech. From a technical perspective, I got first hand proof that REST is sweeping SOAP+WSDL as the technology of choice for building Web services from a diverse and knowledgeable set of folks.  From a personal networking perspective I got to chat with Sam Ruby, Steve Gillmor, Anil Dash, Brad Fitzpatrick, Ben Trott, Erik Benson, Adam Bosworth (the conversation was very interesting, expect more about this in a later post), Marc Canter, Kevin Marks, Jeremy Zawodny, Nelson Minar and a bunch of other people. Then there's the fact that I got to spend time hanging out with folks from work outside of meetings and email discussions.

I find it surprising that there are people who go to conferences to attend talks and 'eat by themselves'. However thinking about it now there definitely is a certain clique-like feel to the entire technology conference scene which I'm sure extends to academic and professional conferences as a while.


 

Categories: Ramblings

Steve Rider, one of the great folks behind start.com, has started a category on his blog devoted to the site. His first post discusses some of the changes they've made to the site in the past week. He writes

As soon as I finish this post I'll be digging in my heels for the afternoon and working on OPML import support and increasing the number of headlines per feed.  Hey, what are rainy Sunday afternoons for?

Here are some of the improvements we've made since we were "discovered" a week and a half ago:

Start.com/1

  • Full Firefox support
  • Migrated from cookie-based solution to back-end store for feeds and preferences
  • Removed the restriction on the number of feeds that can be added
  • Added ability to delete items from My Feeds and Recent Searches
  • Title of module is now hyperlinked (oops) and also gets updated if the title in the RSS feed is different
  • Show search history in correct order
  • Lots of fit and finish and minor cosmetic changes

Start.com/2

  • Fixed a few problems with the ActiveX control that were causing boomarks not to be imported (there are still a couple of issues affecting some users)
  • Added OPML import support
  • Increased performance when fetching from server by making more async calls

One of the features I asked Steve for was OPML import so it's good to see that it's already being added to the site. I didn't realize how fast they'd be turning around on feature requests. Looks like I should dust off my list of feature requests for online aggregators and swing by Steve's office sometime this week. Sweet.


 

Categories: MSN | Syndication Technology

March 20, 2005
@ 07:40 PM

This is the final release of the version formerly codenamed "Wolverine". This is the most significant release to date and has a ton of cool features. Enjoy.

Download the installer from here. Differences between v1.2.0.117 and v1.3.0.26 below.

FEATURES:

Newspaper styles: Ability to view all unread posts in feeds and categories or all posts in a search folder in a Newspaper view. This view uses templates that are in the same format as those used by FeedDemon so one can use RSS Bandit newspaper styles in FeedDemon and vice versa. One can choose to specify a particular stylesheet for a given feed or category. For example, one could use the slashdot.fdxsl stylesheet for viewing Slashdot, headlines.fdxsl for viewing news sites in the News category and outlook-express.fdxsl for viewing blog posts.

Column Chooser: Ability to specify which columns are shown in the list view from a choice of Headline, Topic, Date, Author, Comment Count, Enclosures, Feed Title and Flag. One can choose to specify a column layout for a particular feed or category. For example, one could use the layout {Headline, Author, Topic, Date, Comment Count} for a site like Slashdot but use one like {Headline, Topic, Date} for a traditional blog that doesn't have comments.

Item Deletion: News items can be deleted by either using the [Del] key or using the context menu. Deleted items go to the "Deleted Items" special folder and can be deleted permanently by emptying the folder or restored to the original feed at a later date.

Category Properties: It is now possible to specify certain properties for all feeds within a category such as how often they should be updated or how long posts should be kept before being removed.

del.icio.us Integration: Users who have accounts on the del.icio.us service can upload links to items of interest directly from RSS Bandit.

Skim Mode: Added option to 'Mark All Items As Read on Exiting a Feed'

Scoped Search: Searches can be restricted to specific feeds or categories. So now one can create searches like finding all unread messages that are a week old which contain 'Microsoft' in the title from the Slashdot, InfoWorld or Microsoft-Watch feed.

Search Folder Improvements: Made the following additions to the context menu for search folders; 'New Search Folder', 'Refresh Search', 'Mark All Items As Read' and 'Rename Search Folder'. Also deletion of a search folder now prompts the user to prevent accidental deletion

Subscribing to Web Search Results: Previous versions allowed users to search Web search engines from RSS Bandit, add search engines of their choice as well as specify whether the results were RSS or not. In this version, users can now subscribe to RSS search results after they are returned. By default, MSN Search and Feedster are installed as web search engines with RSS results.

UI Improvements: Tabbed browsers now use a multicolored border reminiscent of Microsoft OneNote.

Identities: One can create multiple personas with associated information (homepage, name, email address, signature, etc) for use when posting comments to weblogs that support the CommentAPI.

Proxy Exclusion List: Users can specify domains which should be accessed directly instead of via the proxy server when making HTTP requests

HTTP Cookie Support: We now support HTTP cookies when requesting feeds.

Delta Encoding in HTTP Support: We support the RFC3229+feed technique when downloading feeds as described at http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html

Better SSL Certificate Error Handling: If there is a problem with the SSL certificate of a site RSS Bandit now provides a dialog with the error information so users can make an informed decision instead of just erroring.

BUG FIXES:

* Fixed issue where a feed with an invalid XML character is encountered it fills the Feed Errors folder with repeated messages whose title begins with "Refresh feed '' failed with error:[], hexadecimal value [] is an invalid character..."

* Comments now sorted from oldest to newest

* Comments now sorted visually differentiated from posts that link to an entry

* Fixed issue where we can't get title from feed that requires username/password in the New Feeds dialog even if they are specified

* Automatic feed detection now ignore feeds a user allready subscribed to

* Fixed issue with ObjectDisposedException sometimes thrown when notification windows pop up

* Fixed issue where if the URL for a feed is changed using the Properties dialog then all old posts are deleted

* Fixed issue where WordPress comment feeds don't show up in RSS Bandit because they use wfw:commentRSS instead of wfw:commentRss

* Clicking on a category node now shows all items from feeds in nested categories as well as child feeds instead of showing items from child feeds only

* Flagged items no longer marked as unread when placed in a flagged item folder

* Fixed issue where updating a search folder's properties leads to duplicate search folders being created

* Fixed issue where errors on loading a cached feed file prevent the feed from being updated from the Web

* Fixed issue where if RSS Bandit is not yet running and you select "Subscribe in default aggregator" within the web browsers context menu or provide url's at the command line, it displays an empty category dropdown.

* URLs containing Cr/Lf no longer cause an error on startup due to a data format XML schema exception

* Locate Feed feature now recognizes Atom autodiscovery links on Blogspot blogs

* Fixed issue where startup position of main window not correct on multi-screen systems

* Fixed issue where we get a feed error when an item in the feed contains an empty slash:comments element


 

Categories: RSS Bandit