Yesterday I wrote a post about the gateway that connects Fargo with WordPress.

In that post, I suggested that it is possible to replace that gateway, which does not handle unicode characters, with one that does. It is possible, and for a reasonably skilled server programmer, not even very much work. In this post I want to outline the problem, at a technical level.

The gateway

• It sits between Fargo and WordPress.

• Fargo is a JavaScript app running in the browser.

• We call the gateway with the jQuery routine $.ajax.

• In our gateway, we call WordPress through the MetaWeblog API, though a new gateway could use a different API, as long as it maintains the same interface to Fargo.

The parameters we send with the request are

• postTitle: the title of the post.

• postBody: the body of the post.

• idPost: the ID of the post, 0 if it's a new post.

• weblogUrl: the URL of the WordPress blog.

• blogUsername: the user's username.

• blogPassword: the user's password.

What the server does

• First, it gets the calling conventions for the blog using Really Simple Discovery to turn weblogUrl into an API address and a blog ID. It caches this result so subsequent calls won't have to go through the full RSD process.

• Then it makes a MetaWeblog API call to the WordPress server. Which call it makes depends on whether idPost is zero or non-zero. If it's non-zero it makes a metaWeblog.editPost call, if it's 0, it makes a metaWeblog.newPost call.

What the server returns

• In all cases it returns a JSONP call, to a routine called getData, with a single param, a JSON struct, that contains several fields.

  • link: points to the blog post.

  • idpost: the WordPress ID for the post, used in subsequent calls to identify the post.

  • error: its presence indicates that the call did not work. Its value is an error string that can be displayed for the user explaining the error.

• The content type of the response is application/json.

Access-Control-Allow-Origin header

• Very important: the gateway must set the Access-Control-Allow-Origin header to fargo.io, so the browser will let Fargo call your service.

Source code

• I'll provide source code for both the $.ajax call from Fargo and the gateway (written in UserTalk running in Frontier) as example-ware.

Business

• I wrote the gateway in January in a couple of days. It took that long because I was unfamiliar with the way the $.ajax process works. It might still take a couple of days to get it up and running and tested and well-enough debugged so users can depend on it. It's the kind of code that takes two or three sessions to complete.

• To deploy, it will have to be on a publicly-accessible server. On Amazon or Rackspace that server would cost less than $100 a month to run.

• One server could easily support the Fargo community, even with a fair amount of growth. WordPress is at this time a fairly small application for Fargo. Of course if it worked better it might be a larger application.

• Doc Searls contacted me today, a Fargo user, who runs a WordPress blog, and he has an interest in making this work, and has offered (I think) to help coordinate.

• I would love to see this as a community development thing. I will show people how to configure Fargo to talk with a different server. We can make it a preference, to make it as easy as possible.

New link for the worknotes site

• There's a link to the Worknotes site in the Docs menu.

• Since the site has moved, the menu item now links to the new location.

Feed for worknotes

• It's also worth mentioning that because we're using Fargo to manage the worknotes, there's now a feed that you can subscribe to:

  • http://docs.smallpict.com/rss.xml

• And because this all is in one place now we can have technotes too, and they will show up in the feed as well.

Fix for the Home icon

• Previously, the home icon (in the left margin) took you to the web view of the named outline. For example, if your outline was named george, the home button would take you to george.smallpict.com. This is usually the right answer.

• However, if you've used the domain attribute to map to a different domain, the web view of the named outline is probably not where you want to go, if your cursor is nested inside the headline with the domain attribute.

• So starting in 0.99, we first check to see if you're inside a domain attributed headline, and if so, we go there.

New verb: op.getCursorUrl

• As its name implies, it returns the URL for the cursor, if it has one, otherwise it returns undefined.

• If the headline is within a page, we return the URL for the page, by shooting out to the summit looking for a node with a type attribute. When we find one, we return its URL. So it's not a precise verb.

• It's good for building redirects, static indices, stuff like that.