PDF Alchemy
PDF Alchemy is an interesting new service that I've helped to build. It's a PDF conversion service aimed at developers - that is, it's entirely API based, and not intended for end users. But what makes PDF Alchemy interesting to me, is the way it uses a number of Amazon's cloud services.
To start with, the PDF conversion servers themselves run on Amazon EC2. EC2 is an excellent match here, since it allows PDF Alchemy to easily, and rapidly, scale to handle almost any possible volume, but also to then scale back again during off-peak periods.
Also, PDF Alchemy makes great use of Amazon SQS queues to manage concurrency and distribution. Of course, SQS does not perfectly guarantee concurrency protection, etc. but applications like PDF Alchemy do not need such guarantees. Indeed, here we can trade off some of that guarantee for greater performance, scalability, and cost efficiency. So again, an excellent match.
As well as EC2 and SQS, PDF Alchemy makes significant use of both S3 and SimpleDB, both providing excellent scalability and cost-effectiveness in their respective areas, allowing the whole PDF Alchemy service to exist entirely in the Amazon cloud in a very nice way :)
It will be interesting to see how this service progresses.
Technorati Tags:
Interesting...
Just looking at the PDF Alchemy site and saw that you provide examples for a bunch of languages. I expected to see c++ in that list, but it's not...
"PDF Alchemy has done the work for you, and includes free working code for you to integrate into your application. Code is available in PHP, Java, C#, VB .NET, ActionScript, Perl, Python and Ruby."
I guess I'm just curious; why no c++?
Why no C++
Good question! :)
Well, I guess the main reason is that there is no built-in HTTP functionality in C++. Of course, C/C++ supports direct TCP socket programming, but PDF Alchemy examples using sockets would be... well, quite painful. And that's before you add HTTPS support via OpenSSL and/or GnuTLS.
So, of course, the way to go with C/C++ would be to use one of the appropriate existing HTTP libraries. So then, it wouldn't really be a single set of C/C++ examples, but rather a set for "C/C++ with libcURL", and another set for "C++ with Chilkat", etc.
Of course, none of that is a problem - just makes it a low priority. And the powers that be judge, quite rightly perhaps, that C/C++ is not the primary expected audience for the service (which is a pity for me, since as you know, C++ is my favorite language - and GnuTLS coding is nothing new to me!).
Anyway, we may well create C/C++ examples sometime, but as it won't be anytime soon, there's no point selling the concept on the website, only to not get around to it for a long time ;)
Good answer
I figured that was the reason, but I was curious - since I know that's the kind of thing you love to do...
Thanks. ;-)
Post new comment