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.
It sits between Fargo and WordPress.
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.
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.
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.
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.
Very important: the gateway must set the Access-Control-Allow-Origin header to fargo.io, so the browser will let Fargo call your service.
I'll provide source code for both the $.ajax call from Fargo and the gateway (written in UserTalk running in Frontier) as example-ware.
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.