Real Simple Discovery Made Easy with the JaySmith.RealSimpleDiscovery Library

Recently I have been spending a lot of time writing blog features for several applications I am working on.  I always have to wire up some of the same handlers for exposing API endpoints for services such as MetaWeblogAPI, Blogger, LiveJournal, etc.  So, being the lazy coder that I am I started looking at ways to make them easier to share between projects. 

In this post I am going to cover a configuration based approach I have developed for handing the first step in exposing those services, Real Simple Discovery.

Real Simple Discovery as described from the RFC posted here is as follows:

Really Simple Discovery is a way to help client software find the services needed to read, edit, or "work with" weblogging software.  Although I talk about weblogging software, there's no reason this format can't apply to other forms of web client/system software that I wasn't considering, or may not even exist as of this writing.  This format is simple but flexible. One of the design goals was to ensure that it would be human writeable. This was my "test" for ensuring that the format was easy for everyone to implement.

What is the benefit of using a handler versus just putting it in an rsd.xml file at your web root?

If you are creating a simple site that is for a single URL and will never be used by others then using an rsd.xml file is an ideal solution.  On the other hand, if you are creating a project that you expect others to install on their own domain they will have to modify the rsd.xml file to provide the full URL to each handler.  This is something you would expect a developer to know how to do but not someone who has just download your code and installed it.  They expect to deploy and it just to run.

Dynamically generating this information allows for a zero config setup where the code that generates the XML can figure out the correct URL’s to provide without the need of manual configuration.  The developer sets up the protocols they want to implement in the web.config file and the real simple discovery handler generates the xml based on that config.  In this scenario the user of the site does not have to setup anything to get it to work

Example rsd.xml from my blog using Blogengine.NET

  <rsd version="1.0">
  <service>
    <engineName>BlogEngine.NET 1.6.1.0</engineName>
    <engineLink>http://dotnetblogengine.com</engineLink>
    <homePageLink>http://jaysmith.us/</homePageLink>
    <apis>
      <api name="MetaWeblog" preferred="true" apiLink="http://jaysmith.us/metaweblog.axd" blogID="http://jaysmith.us/"/>
      <api name="BlogML" preferred="false" apiLink="http://jaysmith.us/api/BlogImporter.asmx" blogID="http://jaysmith.us/"/>
    </apis>
  </service>
</rsd>

Installing JaySmith.RealSimpleDisovery via NuGet

This approach will work for both WebForms and MVC applications since it uses a handler to basically bypass the UI layer.

Example of the config

<realSimpleDiscovery>
    <apis>
      <add name="Atom" preferred="false" apiLink="atom.axd" />
      <add name="Blogger" preferred="false" apiLink="blogger.axd" />
      <add name="MetaWeblog" preferred="true" apiLink="metaweblog.axd" />
      <add name="Manila" preferred="false" apiLink="manila.axd" />
      <add name="MetaWiki" preferred="false" apiLink="metawiki.axd" />
      <add name="LiveJournal" preferred="false" apiLink="livejournal.axd" />
    </apis>
</realSimpleDiscovery>

Navigating to http://[MyHost]/rsd.axd will display the following:

<?xml version="1.0" encoding="utf-8" ?> 
<rsd version="1.0">
  <service>
    <engineName>JaySmith.RealSimpleDiscovery Engine v1.0</engineName> 
    <engineLink>https://github.com/JaySmith/RealSimpleDiscovery</engineLink> 
    <homePageLink>http://localhost:4104/</homePageLink> 
    <apis>
      <api name="MetaWeblog" preferred="True" apiLink="http://localhost:4104/metaweblog.axd" blogID="http://localhost:4104/" /> 
      <api name="Atom" preferred="False" apiLink="http://localhost:4104/atom.axd" blogID="http://localhost:4104/" /> 
      <api name="Blogger" preferred="False" apiLink="http://localhost:4104/blogger.axd" blogID="http://localhost:4104/" /> 
      <api name="Manila" preferred="False" apiLink="http://localhost:4104/manila.axd" blogID="http://localhost:4104/" /> 
      <api name="MetaWiki" preferred="False" apiLink="http://localhost:4104/metawiki.axd" blogID="http://localhost:4104/" /> 
      <api name="LiveJournal" preferred="False" apiLink="http://localhost:4104/livejournal.axd" blogID="http://localhost:4104/" /> 
    </apis>
  </service>
</rsd>

Another feature is that the implementation is flexible enough to handle new APIs as they become available.  To expose a new api all you have to do is add it to the web.config file and the end point of the new api will be generated just like all the rest.

Example of new API

  <realSimpleDiscovery>
    <apis>
      <add name="Atom" preferred="false" apiLink="atom.axd" />
      <add name="Blogger" preferred="false" apiLink="blogger.axd" />
      <add name="MetaWeblog" preferred="true" apiLink="metaweblog.axd" />
      <add name="Manila" preferred="false" apiLink="manila.axd" />
      <add name="MetaWiki" preferred="false" apiLink="metawiki.axd" />
      <add name="LiveJournal" preferred="false" apiLink="/api/livejournal.axd" />
      <add name="MyNewApi" preferred="false" apiLink="/mynewapi.axd" />
    </apis>
  </realSimpleDiscovery>

Output with new API after navigation to http://[myhost]/rsd.axd

<?xml version="1.0" encoding="utf-8" ?> 
<rsd version="1.0">
<service>
  <engineName>JaySmith.RealSimpleDiscovery Engine v1.0</engineName> 
  <engineLink>https://github.com/JaySmith/RealSimpleDiscovery</engineLink> 
  <homePageLink>http://localhost:4104/</homePageLink> 
 <apis>
  <api name="MetaWeblog" preferred="True" apiLink="http://localhost:4104/metaweblog.axd" blogID="http://localhost:4104/" /> 
  <api name="Atom" preferred="False" apiLink="http://localhost:4104/atom.axd" blogID="http://localhost:4104/" /> 
  <api name="Blogger" preferred="False" apiLink="http://localhost:4104/blogger.axd" blogID="http://localhost:4104/" /> 
  <api name="Manila" preferred="False" apiLink="http://localhost:4104/manila.axd" blogID="http://localhost:4104/" /> 
  <api name="MetaWiki" preferred="False" apiLink="http://localhost:4104/metawiki.axd" blogID="http://localhost:4104/" /> 
  <api name="LiveJournal" preferred="False" apiLink="http://localhost:4104/api/livejournal.axd" blogID="http://localhost:4104/" /> 
  <api name="MyNewApi" preferred="False" apiLink="http://localhost:4104/mynewapi.axd" blogID="http://localhost:4104/" /> 
  </apis>
 </service>
</rsd>

You can see that the new MyNewApi endpoint has been included.

Looking for feedback

I am really looking for feedback on this approach so if you are creating applications that need to use Real Simple Discovery please give this a test drive and let me know of any improvements you would like to see.

Resources on Real Simple Discovery:

RFC: Really Simple Discoverability 1.0

http://archipelago.phrasewise.com/display?page=oldsite/1330.html

http://cyber.law.harvard.edu/blogs/gems/tech/rsd.html

Inbox Zero: Free yourself from the Inbox Dungeon

image

On March 26, 2011 I was meeting with Tim Rayburn and Devlin Liles at our first RoundTable (More info on this coming) meeting.  The conversation at some point turned to Inbox Zero.  I had heard of it but had to admit I wasn’t really sure what it was all about.  I stated that I didn’t think I could achieve zero emails in my inbox and the best I could hope for was to reach zero unread.  Yes, at the time I had over 2000 emails in my inbox.

Tim chided me for such a practice and started discussing the virtues of inbox zero.  That was enough for me to seriously reconsider my thinking.  So, on Monday morning I set about to learn about inbox zero.  After watching Inbox Zero by Merlin Man on YouTube, truly inspired I set about employing the techniques outlined by Mr. Man and have been greatly pleased with the results.  So much so that I wanted to put a post together discussing what worked for me and why in the hopes that others can free themselves form Inbox Dungeon.

If you can take care of it in two minutes or less do so and delete it

This is one of my favorites, if you can do it in two minutes or less just do it and delete.  Done! Gone, not more worries. 

If it is something you need to reply to but can’t in two minutes or less move it to a “To Respond” folder

This has turned out to be an awesome strategy, not only does it get it out of the inbox it allowed me to discover a really interesting feature of Outlook.  I didn’t realize that Outlook had a feature that if you reply to an email from a folder other than you Inbox it will put the reply in the same folder.  This has turned out to be a huge timesaver, if I am ready to archive both of those emails I can select them both and move them instead of having to dumpster dive the “Sent Items” folder.

If at the same time you strive to implement 5 Sentences or Less then creating the responses becomes even easier.  What do you usually do when you get an extremely wordy reply to a simple question?  Scroll to the bottom and find the main points and actions, right?  So, write your response to only include the main points and actions.  This will not only increase your time to reply it will also reduce the amount of time the other person spends trying to figure out the information.

If I can’t reply in 5 sentences or less I pick up the phone and call.  This is usually because there are questions that need to be answered before I can fully compose my response.  Instead of creating a very lengthy email thread that may takes hours or even days of back and forth, just pick up the phone, have the conversation, get the questions out of way.  Remember the goal is to reduce the amount of time spent on items in your inbox so you can spend more time on work that brings value.

Don’t let you inbox be your task list

A great point made by Merlin was that you inbox is not a task list and should not be used as such.  If you need to do something because of an email, we all get work request via email, then remove it from the inbox and put it on a task list.  Then work your task list as normal.  Having task in multiple places causes productivity issues due to all of the switching from one list to the other and often results in things being missed or forgotten.

Don’t make archiving emails too difficult.

I had about 25 folders in my personal archive that I used to catalog emails.  I couldn’t remember any time I had really needed to find an email in those folders and if I did I used the search in my email client.  So, why was I putting them in all of those folders if they didn’t add any value?  I know have one “Archive” folder where all things important that need to be saved for a while are put, a few specific project folders and one for each application I support.  The application support folders will probably go away as soon as I put some time into pruning them.

Summary

In summary I have been using the techniques for about a month now and have been able to achieve Inbox Zero every day.  I only have to process about 10 emails at a time, which means I get them done very quickly and get to return to more important work.  If you are stuck in you inbox all the time I recommend you give this a try, and decide for yourself if this frees up more of your time to spend on more valuable task.  I know it did for me.

Calendar

<<  November 2017  >>
MonTueWedThuFriSatSun
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

View posts in large calendar

Month List