Thursday, December 19, 2013

A Better Cloud Printer II - API interface

This post continues from my earlier post:

The API definition

So I have got my software stack on a drawing board, next is to make it happen with actual code. RestFul API requests are defined in JSON format:

// this is the very 1st API definition, print out something to a remote printer
{
  "sid"         :"asdfasdf",
  "secret"      :"13wd23d2323r",
  "apiversion"  :"2014-01-01",
  "service"     :"submit",
  "parameter"   :{
      "printerid"   :"asdf2323wd2e",
      "title"       :"xxxxxxx",
      "content"     :"xxxxxxx",
      "contentType" :"PLAINTEXT"
  }
}

  // Response
  {
    "jobid" :"xxxx",
    "status":"ok",  // in progress, fail, ...
    "printerid" :"xxxx"
  }
  


Will update the progress soon....

*Edit 2013-12-27

I have been working on this thing during the holiday season. The rough framework code for public API has been setup as follows:

Public facing software stack: Centos + Nginx + PHP + mySQL + GearMan
PHP libraries are:
  • Luracast Restler - the framework handles RESTful requests
  • Idiorm - ActiveRecord library. (When I am too lazy to write real SQL queries)
  • Whole bunch of PHP utility functions I wrote in the past.
Although the rage is all about Redis and Node.js, I don't see a compelling reason to use the newer software stack. Call me old school:
  • Print API data is strictly structured, saved to database as json encoded string.
  • RESTful, no state between requests.
  • The API will return right after been fired.  (before the actual printer output is finished)
  • Client Callback url for job status update.
Why not Redis/Node/Mongo/Riak/Erlang/whatever?  With Nginx + PHP-fpm, this setup should easily handle 100+ requests/sec on a very cheap VPS(by cheap,  I mean $5 per month).  And I don't see it reaching that limit with a deployment of less than 2000 printers.  If I ever run out of server capacity, the fortune is on my side.  I should already be making enough money to upgrade the servers.

For the actual worker process that handles individual request processing, I might consider something runs on top of libev as daemon.  Could be Node.js or Python Twisted, will leave that for later decision.

*Side note: I am thinking about opensource the entire thing on Github, anyone interested?
If someone can help manage the repo, I'll make it happen.


4 comments:

  1. I'm an amateur developer and would love to get access to this code for a small hobby project of mine which involves the adafruit thermal printer and a raspberry pi. If you did put it on github I would do what I could to help :) cheers Stan

    ReplyDelete
    Replies
    1. Hi Stan, Thanks for your interest in the project! I will definitely let you know when it is ready for a alpha release. Right now the code is not quite ready because it still miss a few important function: security, user validation, printer management etc...

      Delete
    2. Hi Stan and Reed! We would love to contribute to this open source project. For brake rotors in our shop, we need a solution that prints a small pick-pack receipt after a customer or salesperson places an order. Gets order from Ruby-on-Rails app in the cloud and then sends a simple receipt print command to this type of device. We are very interested in this. We are also building a process control solution using PubNub, and I think it would work well for this application to signal when something needs to be printed...

      Delete
    3. Hi Prescott, I am happy to see you find value in this project. But the bad news is, the code base has never been completed to a state that could be opened. I have stopped working on it a while ago.

      But with the information on this blog, you should be able to easily make such a printer yourself. I wish you good luck with your project.

      Reed

      Delete