Expanding upon the concept of an earlier contextual project called Dashboard, Gmail contextual gadgets give a clear message that email, as a universal information carrier and workflow pipeline, is not only here to stay, but is being given a new lease of life as it plays a foundational role in Google’s enterprise scale application platform strategy. A Gmail contextual gadget enhances email messages by providing information or functionality that is relevant to the context of that email … right inside the email itself. Context is exposed by content extractors in the form of ‘clues’ in Gmail (akin to Dashboard’s ‘cluepackets‘) and matched content is provided to the gadget at runtime.

Extractors, optional filters, and scope declarations (used by the installer of a gadget to decide whether to install or not based upon privacy and security requirements) are defined in a manifest, along with references to the gadgets themselves, via gadget spec files, that are to be triggered.

What makes these Gmail contextual gadgets even more attractive is the Google Apps Marketplace, where developers can make gadgets available, and consumers can use the “Add it now” button to start using them in their own domains.

Developing Gmail contextual gadgets is relatively straightforward, but there are a few things that might cause you to stumble, such as documentation (we’re early adopters!), cacheing issues and not being completely aware of what match information is provided.

Despite the advent of Wave and Buzz, it’s obvious that Google sees, rightly in my opinion, a tremendous amount of value in the venerable email application, and I thought I’d take the opportunity to document my first attempt at enhancing the contextual experience with a Twitter-flavoured Gmail contextual “Hello World” gadget.

Twitter User Info

‘Twitter User Info’ is a Gmail contextual gadget that provides basic info about Twitter users whose Twitter handles appear in the email Subject line. In this example, the profile image and basic Twitter user info is shown for Joseph, whose Twitter handle @jcla1 appears in the Subject of the email from Michelle:

The contextual gadget appears directly below the email body, and starts with the title and description “Twitter - User Info” (defined in the gadget spec) and contains HTML showing the Twitter info.

Components and hosting

What are the components that make up this gadget? First of all, we need the manifest and the gadget spec itself. To support the dynamic creation of contextual content in the email, we will be using jQuery, not only because it’s a fantastically useful and powerful library for manipulating web page content, but also because of Google’s intention to use Caja to provide a layer of protection for the user of Javascript-based apps. The jQuery library is listed as one of the development frameworks that will be compatible with Caja. There’s also a tiny bit of CSS.

Beyond that, we will of course be making a call to one of the Twitter API endpoints, and calling upon one of my favourite HTTP tools PostBin, to dump Google gadget libary method return values for inspection.

While the manifest is uploaded to Google when you make your gadget available in the Marketplace, your gadget spec needs to be accessible online (so the gadget container can pull it in at the appropriate moment). There are many options for hosting content online, but for this experiment I decided to create a new App Engine application ‘qmacro-contextual‘ and host the gadget and CSS as static files there (I’m also storing the manifest there too). This might appear as overkill, but as I progress further into contextual gadget development, I will most definitely want to do some of the heavy app lifting outside of the actual gadget spec, and for this, App Engine is ideal.

Here’s part of the app.yaml file showing the handler declarations for the static manifest, gadget and CSS resources:

application: qmacro-contextual
version: 1
runtime: python
api_version: 1

handlers:
- url: /manifests
  static_dir: manifests
  expiration: 1m

- url: /gadgets
  static_dir: gadgets
  expiration: 1m

- url: /css
  static_dir: css

- url: .*
  script: main.py 

Note that I’ve specified an expiration period of 1 minute for the manifest and gadget spec directories. This is for development only, so that I can be sure that at least App Engine will serve up the resources with a very short shelf life, so that I can tweak the definitions and code and have them reloaded by the gadget container.

Incidentally, there’s also a URL query string parameter you can specify that causes gadget cacheing to be turned off - just append “?nogadgetcache=1″ to the Gmail URL and this should do the trick.

The Manifest

I followed the Developer’s Guide to construct the manifest, which you can see here in full:

http://qmacro-contextual.appspot.com/manifests/twitter-user-info.manifest.xml

The interesting parts of the manifest which relate to Gmail contextual gadgets are the Extractor, Gadget and Scope declarations.

The Extractor declaration looks like this:

<!-- EXTRACTOR -->
<Extension id="SubjectExtractor" type="contextExtractor">
  <Name>Twitter IDs in Subject</Name>
  <Url>google.com:SubjectExtractor</Url>
  <Param name="subject" value=".*@[a-z]+.*"/>
  <Triggers ref="TwitterUserInfoGadget"/>
  <Scope ref="emailSubject"/>
  <Container name="mail"/>
</Extension>

Each extractor (there can be more than one for any given manifest) is defined with an id and name and references a particular Extractor ID which does the work of pulling the info out of the email. Here we’re referencing google.com:SubjectExtractor, which is an extractor provided by Google for pulling out the Subject line. Google will be opening up opportunities for developers to build their own extractors if the pre-defined ones don’t provide what we need.

The google.com:SubjectExtractor is defined as returning one output field, @subject, which is made available to the gadget to do with as it wishes - more on that later. It also has one scope defined, tag:google.com,2010:auth/contextual/extractor/SUBJECT, which must be linked with a scope definition in a later section of the manifest.

We can see the reference to the @subject output field in the <Param/> tag. This is a filter definition, which says here that we only want the extractor to trigger the gadget if the email subject matches the given regular expression - i.e. if it contains a Twitter handle. Clearly, we want to avoid triggering gadgets when there’s nothing for the gadget to do; not only to avoid unnecessary almost-empty gadget displays, but also for performance reasons; without a filter, this extractor would fire for every email you looked at. The filter is optional, but Google recommends that even if you want to match on every occurrence, you put an explicit catch-all regular expression “.*” to make that clear.

The reference to “TwitterUserInfoGadget” points to the next declaration, that of the gadget itself:

<!-- GADGET -->
<Extension id="TwitterUserInfoGadget" type="gadget">
  <Name>Twitter User Info contextual gadget</Name>
  <Url>http://qmacro-contextual.appspot.com/gadgets/twitter-user-info.gadget.xml</Url>
  <Container name="mail"/>
</Extension>

The id of the gadget, “TwitterUserInfoGadget” is what is referred to in the <Triggers/> tag of the previous Extractor declaration. The gadget is a resource, located at

http://qmacro-contextual.appspot.com/gadgets/twitter-user-info.gadget.xml

and this is what will be requested by the Gmail contextual gadget container to pull in the gadget spec. Here’s part of an App Engine log record showing the gadget spec being fetched:

The name declared in this Gadget declaration (”Twitter User Info contextual gadget”), along with the name in the Extractor declaration (”Twitter IDs in Subject”) and the general name and description from elsewhere in the manifest, are text items that appear to the Google Apps domain administrator when selecting the gadget for installation, like this:

Finally, we have the Scope declaration, which was indicated in the Extractor declaration earlier. This is “emailSubject”, and contains the scope URI defined for the extractor being used. There may be more than one scope for a given extractor; if this is the case, they must be each defined separately and explicitly.

<!-- SCOPE -->
<Scope id="emailSubject">
  <Url>tag:google.com,2010:auth/contextual/extractor/SUBJECT</Url>
  <Reason>This application looks at the subject of each email
     looking for Twitter handles</Reason>
</Scope>

This information appears during gadget installation, where the administrator can review what the gadget will access, and decide whether or not to proceed:

Once you’ve defined your manifest, you must upload it as part of the overall Listing Information required to offer a gadget or an app on Google Apps Marketplace. You have to sign up to become a vendor with Google in order to do this. It’s free, as is the listing of unpublished test gadgets and apps, so you can experiment all you need to.

The Gadget Spec - Declarations

Now we’ve dealt with the manifest, it’s time to turn our attention to the gadget spec. Remember that the gadget is triggered when we get a Subject line that contains one or more Twitter handles. If you’ve developed a gadget before, for iGoogle, for example, this should be familiar to you. First we have the ModulePrefs section where we declare basic gadget information and the features that we require. There’s a feature specific to Gmail contextual gadgets that we must declare here. Then we have the gadget code itself, in a CDATA section.

Here’s what the ModulePrefs section looks like:

  <ModulePrefs title="Twitter"
    description="User Info"
    height="50"
    author="DJ Adams"
    author_email="dj.adams@pobox.com"
    author_location="Manchester">

    <Require feature="dynamic-height"/>
    <Require feature="google.contentmatch">
      <Param name="extractors">
        google.com:SubjectExtractor
      </Param>
    </Require>
  </ModulePrefs>

The title and description in the module prefs shows up (”Twitter - User Info”) when the gadget is displayed at the bottom of the email. We define a height for the gadget which can be auto-adjusted later with the dynamic-height feature declared in this section too. A feature that’s specific to Gmail contextual gadgets, and that must be declared for all such gadgets, is google.contentmatch. In declaring this feature, you must list the Extractor id (or ids) that will be triggering this gadget.

The google.contentmatch feature gives us the facility we need to avail ourselves of the, ahem, content that was matched in this context. As you will see, we use the getContentMatches() method to do this.

The Gadget Spec - Code

With the ModulePrefs declarations out of the way, we get to the Javascript that breathes life into our gadget. The Javascript is defined in the <Content/> tag. The view type “card” is the only one supported by Gmail contextual gadgets right now.

<script type='text/javascript' src='http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js'></script>
<script type="text/javascript">

  // Expect subject as first element keyed by 'subject'
  matches = google.contentmatch.getContentMatches();
  jQuery.post('http://qmacro-postbin.appspot.com/1jd620g', 'matches:' + JSON.stringify(matches));
  var subject = matches[0]['subject'];

  // Only do something if we actually have a subject to work with
  if (subject) {

    // Pick out the twitter @handles and process them
    var handles = subject.match(/@[a-z0-9_]+/g);

    if (handles) {
      $('head').append('<link rel="stylesheet" href="http://qmacro-contextual.appspot.com/css/twitter-user-info.css" />');
      for (var i = 0; i < handles.length; i++) {
        var user_resource = 'http://api.twitter.com/users/show/'
                          + handles[i] + '.json?callback=?';
          $.getJSON(user_resource, function(data) {
          jQuery.post('http://qmacro-postbin.appspot.com/1jd620g', 'userinfo:' + JSON.stringify(data));
          var loc = "";
          if (data.location) {
            loc = ' (' + data.location + ')';
          }
          var tw_info = '<table border="0">'
                      + '<tr>' + '<td>' + '<a href="' + data.url + '">'
                      + '<img src="' + data.profile_image_url + '" />' + '</a>'
                      + '</td>' + '<td class="userinfo">'
                      + '<a href="http://twitter.com/' + data.screen_name + '">@'
                      + data.screen_name + '</a>' + '<br />' + data.name + loc + '<br />'
                      + data.description + '</td>' + '</tr></table>';
          jQuery(tw_info).appendTo('body');
        });
      }
      gadgets.window.adjustHeight(100);
    }
  }

</script>

First, we pull in the jQuery library with a <script/> tag, and then we’re off with our gadget code.

We use the google.contentmatch.getContentMatches() method to pull in the matches supplied to us by the Extractor. One of my favourite phrases is “let the dog see the rabbit” - let’s have a look at the data, in this case. What does the getContentMatches() actually return? What does it look like? This is where the rather useful PostBin comes in to play. When we get the response from the call to getContentMatches(), encode it into a JSON string form with JSON.stringify() and bung the whole lot to a Postbin too see. Easy! Of course, this is only appropriate for development and debugging - I’d remove it for a production gadget. By the way, I’m running my own instance of Postbin - you can run you own instance too.

So from looking at what we get, we can see that what we’re after is the value of the ’subject’ key in the first element of the matches array.

By definition, we’re only instantiated because there was a Twitter handle in the Subject. There could be more than one, of course. After collecting them into a handles array, we’re ready to process each one. First, though - we pull in the CSS resource to the current document. The resource is served as a static file from the App Engine app:

http://qmacro-contextual.appspot.com/css/twitter-user-info.css

For each of the Twitter handles, we want to display some basic info, as shown in the screenshot earlier. To retrieve this, we make a simple call to the Twitter API. Specifically,

http://api.twitter.com/users/show/[Twitter-handle].json?callback=?

will give us a nice chunk of JSON with the information we want, like this:

{
 "description":"Developer and Linux Expert",
 "screen_name":"Jcla1",
 "url":"http://www.pipetree.com/josephadams",
 "name":"Joseph Adams",
 "profile_image_url":"http://a1.twimg.com/profile_images/106288960/JosephWithLomaxCar_normal.jpg",
 "location":"Krefeld,Germany",
 ...
}

I’d originally started with the jTwitter jQuery plugin but found that it didn’t quite do what I wanted, and in any case using the Twitter API from jQuery is straightforward anyway. But thank you uzbekjon for getting me started.

You can see from the code that I’m making more use of Postbin, by gratuitously dumping the results of the Twitter API call in there too. I like to see what I’m dealing with. Data::Dumper is my alltime favourite Perl module, if you hadn’t guessed.

Once we have the info from Twitter, it’s just a simple matter of constructing some HTML, making use of the CSS via the ‘userinfo’ class, and appending that to the email. Job done!

I’ve pushed my fledgeling qmacro-contextual App Engine project to Github, so you can take a look and create your own “Hello World” Gmail contextual gadget.

Share and enjoy!

Hooked!

Since then we’ve been fans of the game of endless possibilities and ever changing scope and interest, and almost regulars at our local MTG store, Fan Boy Three on Newton St in Manchester.

So to educate myself in all thing Magic, I turned to MTG’s official website, Wizards of the Coast’s The Multiverse, and in particular, to their incredibly prolific set of column authors on the Daily MTG. More articles on design, deck construction, strategy and match reports than you could shake a Planeswalker card at.

But while I read a lot, the majority of it is on paper, in the bath, on the train, and soaking up the countless minutes lost at the start of every meeting, while you wait for people to get started, fail to get the projector working, fetch coffees or fiddle with the air conditioning. And on paper, the MTG articles are good, but for a novice like me, there’s something missing. The articles make lots of references to cards by name, and when reading online, there’s a nice popup of the card details so you can see what the author is talking about. But on paper?

So I had an itch to scratch. What I wanted was an accompanying printout of the cards mentioned in any given Daily MTG article. So when the author referred to Hedron Crab,  Baloth Woodcrasher or Oran-Rief, the Vastwood I would know what they were talking about.

I decided to use Google App Engine, and have my Python HTTP responder in the cloud. I created a very simple app “mtgcardinfo”, part of my Github-hosted scratchpad area gae-qmacro. Given the URL of an MTG article, the app uses urlfetch() to go and get it, parses out the card names, and produces an HTML response with a whole load of image references. Luckily the card detail popups in the articles are powered by Javascript and are great indicators of card names for anyone who cares to wield a regex to look for them.

And of course to glue it all together, I used a bookmarklet, so I could jump to the list of cards while directly in the article.

So if you’re interested, have a go: http://qmacro.appspot.com/mtgcardinfo.

The combination of App Engine, Python, HTTP and Javascript is rapidly becoming my new Swiss Army Knife of choice in the web-based online world. And the best thing? I’m teaching Joseph this stuff, and not only is he incredibly good at it, he *loves* it!

The offerings are slightly different - for example, while EC2 is bare virtual hardware, App Engine is a web application platform in the cloud. But they all have similar pricing arrangements, based generally on uptime or CPU time, I/O  and storage.

Does this seem familiar to you? It does to me, but then again, I did just turn 0×2B this month. In 1988 I was working in the Database Support Group at a major energy company in London, looking after the SAP R/2 databases, which were powered by IMS DB/DC, on MVS - yes, IBM big iron mainframes. I still look back on those days with fond memories.

In reviewing some 3rd party software, I wrote a document entitled “BMC Software’s Image Copy Plus: An Evaluation“. BMC’s Image Copy Plus was a product which offered faster image copies of our IMS DB (VSAM) databases. (Image Copy Plus, as well as IMS, is still around, over 20 years on! But that has to be the subject of another post).

One of the sections of the evaluation was to compare costs, as well as time — by how much would the backup costs be reduced using BMC’s offering?

And have a guess on what the cost comparison was based? Yes. CPU time, I/O (disk and tape EXCPs) and actual tapes.

Everything old is new again.

I got my Wave Sandbox account a week or so ago, and have had a bit of time to have a look at how robots and gadgets work — the two main Wave extension mechanisms. To get my feet wet, I built a robot, which is hosted in the cloud using Google App Engine, another area of interest to me, and the subject of this weblog entry. I used Python, but there’s also a Java client library available too. You can get more info in the API Overview.

What this robot does is listen to conversations in a Wave, automatically recognising SAP entities and augmenting the conversation by inserting extra contextual information directly into the flow. In this example, the robot can recognise transport requests, and will insert the request’s description into the conversation, lending a bit more information to what’s being discussed.

The robot recognises transport requests by looking for a pattern:

trkorr_match = re.search(' (SAPK\w{6}|[A-Z0-9]{3}K\d{6}) ', text)

In other words, it’s looking for something starting SAPK followed by six further characters, or something starting with 3 characters, followed by a K and six digits (the more traditional customer-orientated request format). In either case, there must be a space before and a space following, to be more sure of it being a ‘word’.

How does it retrieve the description for a recognised transport request? Via a simple REST-orientated interface, of course I use the excellent Internet Communication Framework (ICF) to build and host HTTP handlers so I can expose SAP functionality and data as resources in a uniform and controlled way. Each piece of data worth talking about is a first class citizen on the web; that is, each piece of data is a resource, and has a URL.

So the robot simply fetches the default representation of the recognised request’s ‘description’ resource. If the request was NSPK900115, the description resource’s URL would be something like:

http://hostname:port/transport/request/NSPK900115/description

Once fetched, the description is inserted into the conversation flow.

http://www.youtube.com/watch?v=G7W2M6H3OQo

(Originally written on SDN but republished here because of portal access issues)

To give you a bit of background, I’m an SAP veteran of 22 years – starting out with R/2 version 4.1d in 1987, moving through R/3 in the mid-90’s and on to Enterprise and beyond. But this is the first time I’ve studied SAP Business ONE in any detail. So while I have a lot of experience of SAP’s traditional products, I’m approaching SAP Business ONE, and “SAP Business ONE Implementation” more as the potential owner of a small business.

I certainly haven’t been disappointed. “SAP Business ONE Implementation” is written “for technically savvy business owners, entrepreneurs and departmental managers”. And I think by and large the book does a great job of reaching out to and connecting with exactly that audience. I was expecting the book to be a fairly technically orientated implementation how-to. But it is more than that. It takes you from business first principles, connecting well at the level of sales, delivery, inventory, warehousing, manufacturing and other business challenges. It explains how SAP Business ONE is designed to address those challenges, and guides you through installation, implementation and some configuration of the system. Once the basics have been established, it moves further to cover project planning, reporting and analysis, business process analysis, customer relationship management, logistics & supply chain management, contract management, and ends up addressing, albeit briefly, more complex reporting tools and topics, data migration, and electronic commerce.

The book has fewer than 300 pages. A book that addresses the areas that this book does could easily be twice that size. But that’s where this book does well. It’s an approachable, undaunting and really rather good introduction to running your business with SAP Business ONE. The writing style is very easygoing, and informative without being patronising. There are plenty of examples, and all the screenshots you’d need. It doesn’t try to be a reference book. It does try to be a sort of hybrid guide to solving the business and technical challenges of running a small or medium sized company using SAP software, and I would say that it succeeds.

If you’re a small business owner considering stepping up and taking control of your business with SAP Business ONE, if you’ve already got SAP Business ONE and want to explore more application features at a high level, or if even if (like me) you’re an SAP hacker wanting to learn about what SAP Business ONE can do, then you could do a lot worse than grab a copy of this book.

]]> http://www.pipetree.com/qmacro/blog/2009/08/book-review-sap-business-one-implementation/feed/ http://www.pipetree.com/qmacro/blog/2009/08/dealing-with-blogtheft-from-saps-developer-network/ http://www.pipetree.com/qmacro/blog/2009/08/dealing-with-blogtheft-from-saps-developer-network/#comments Fri, 28 Aug 2009 15:14:53 +0000 dj http://www.pipetree.com/qmacro/blog/?p=745 Recently it has come to people’s attention that there is a website www.sap-abap4.com out there with a lot of very interesting content … which seems to have been completely “lifted” from the SAP Developer Network (SDN) and reproduced verbatim, except that in each case the original author name has been removed!

Lots of discussion is taking place how best to deal with this. One way (and I’m posting it as a blog entry as much for my memory’s sake as anything else) is to conditionally rewrite requests for images. I’m using Apache and therefore the mod_rewrite extension is my tool of choice.

It just so happens that there are a couple of screenshots in a recent SDN blog entry of mine “A return to the SDN community, and a touch of Javascript” and these images are hosted on my own server at www.pipetree.com.

So as a little test, I can control the requests for these images, rewriting those requests so that a different image is served depending on the request’s referrer — the URL of the page that the images are referenced on with an <img /> tag.

So with some mod_rewrite voodoo in a local .htaccess file:

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http://www\.sap-abap4\.com
RewriteBase /qmacro/x
RewriteRule ^SdnPageTitle(Fixed|Broken)_small\.jpg$ StolenContent.png [L]

I can send a ‘StolenContent.png’ image, if the referrer is from the rogue site.

The result of the rewrite is that when viewed on SDN, the blog entry looks fine, and the screenshot images look as they’re supposed to:

Images appear as they're supposed to

But when the images are used on www.sap-abap4.com, they will appears differently:

Image appears differently

So there you have it. It’s not a complete solution to the problem by any means, but it at least will alert unsuspecting readers of that website to what’s happening (if you’re testing yourself, you might have to refresh the pages in your browser, as it will probably have cached the first version of each image). Perhaps the SAP community network team can apply this technique for the images hosted on SDN.

Consider for a moment what this command line of the future might look like. More and more people are online. More and more people are permanently connected, whether it be through DSL, cable, or 802.11 technology. And more and more of these people are communicating. Talking. Having conversations. In addition to email and Internet Relay Chat, or IRC, the (relatively) new kid on the block, Instant messaging (IM), is playing a huge part in facilitating these conversations. And in the same way that it’s common for us to have a command prompt or three sitting on our graphical desktop, it’s also becoming common to have chat windows more or less permanently open on the desktop too.

But when thinking of IM, why stop at conversations with people? The person-to-application (P2A) world isn’t the exclusive domain of the Web. Bots, applications or utilities that have their interface as a projection of a persona into the online chat world, are a great and fun way to bring people and applications together in a conversational way.

Interacting with a bot is the same as interacting with a person: type something to it and it replies. And what’s more, because of the similarities between a classic command-line prompt and that of a chat window, where you’re talking with a bot — both scenarios are text-based — interaction with a bot is scriptable.

Forward to the present.

Just the other day, @davemee and @technicalfault alerted me to @manairport, Manchester Airport’s online persona on Twitter, obviously yet another chat-style interface. You can interact with it via direct messages (DMs). You follow it, it will follow you back, and you’re away.

me: d manairport be7217

manairport: Received request for information: be7217
manairport: Status of 17:40 flight BE7217 to Dusseldorf
            departing T3: Scheduled 17:40

Nice and useful!

And then just this morning, I read a weblog post on SDN entitled “SAP Enterprise Service and Google Wave“. In it, the author talks about connecting Google Wave (you guessed it, yet another chat-style interface, amongst other things) with SAP, in particular enterprise ’services’. In the short demo, order information from an SAP system is retrieved in a conversational way. The concept is great. The obvious issue with what’s shown in the demo (and I know it’s only a proof of concept) is that the bot responds with a data structure dump of information. What we’re looking for is something more, well, consumable by humans. Smaller, more distinct and addressable pieces of information that can be returned and be useful.

But what was more telling, at least to me, were the difficulties he described in connecting to the complex Enterprise Service backend in SAP:

“… find the webservice … create a proxy … I did have some problems with calling the ES … On Appengine there are some limitations on what you can call of Java classes … From an architectural point I’m not real proved of the solution…”

Hmm. Why does architecture have to be complex? Using Enterprise Services, using SOA, is more complex than it needs to be. There’s a reason why the web works. There’s a reason why Google designed App Engine’s backend infrastructure (including asynchronous task queues) in a simple HTTP-orientated way. There’s a reason why the Wave robot protocol is based on simple HTTP mechanisms. There’s a reason why mechanisms like PubSubHubBub and Webhooks are based on HTTP as an application protocol. Because simple works, and it works well.

Let’s come back to the “smaller, more distinct and addressable” issue. If we let ourselves be guided by a Resource Orientated Architecture (ROA) approach, rather than a Service Orientated Architecture (SOA) approach, we end up with simpler application protocols, flexible, reliable and transparent integration, and pieces of information that are addressable — and usable — first class citizens on the web. This is Twitter’s killer feature.

Enterprises suffer enough with complexity paralysis. We should endeavour to embrace the design of HTTP as an application protocol (which is what I’m doing with Coffeeshop), rather than fight against it.

http://www.youtube.com/watch?v=NhAWH2-Quuk

In this shorter screencast, I continue on from where I left off — viewing the message detail resource in the web browser. I use conneg to request that same resource in JSON instead of HTML, and show how the JSON representation can be easily parsed, and the data reused, further along the pipeline.

This time, the coffeeshop instance I’m using is one running on Google’s App Engine cloud infrastructure — on appspot.com.

http://www.youtube.com/watch?v=TI48cdpWOBg

In the screencast, I also make use of Jeff Lindsay’s great Postbin tool for creating the recipient resources for the Subscribers. It was originally created to help debug Webhooks, but of course, a Subscriber is a sort of Webhook as well. (Postbin runs on App Engine too!).

However, I must call him on this small statement:

“XMPP is way too complicated for any normal human to deploy”

Compared to what? I’m getting the idea that he’s referring to ’simpler’ mechanisms such as HTTP or SMTP servers. Simpler? Has Anil modified a sendmail config file recently?

These days setting up an XMPP server is pretty straightforward. Then again, I am perhaps somewhat biased