The Webmechs Press

FPGAs or Field Programmable Gate Arrays are essentially programmable/reconfigurable hardware. A particular CPU architecture can be thought of as hardcoded whereas in contrast, FPGAs let you change the processor “architecture” any time you like. The trade-off is performance versus flexibility. While their gate configurations are reprogrammable, the different process utilized to make FPGAs mean that their switching speeds are going to be far slower than with dedicated gate designs.

On the other hand, the fact that you can tailor the “hardware” for a particular task or algorithm means that it has the potential to execute way way faster than implementing that algorithm in terms of a fixed assembly language instruction set. The caveat is that assembly language is pretty cumbersome as it is and programming at the gate level is going to be an even lower-level task.

The apparent return you get for having to endure the much more difficult programming task is that you effectively get much more computing power for the same amount of energy/power consumed. The analogy would be that of using a lower-level language to wring more performance out of less powerful hardware.

http://www.fhpca.org/
http://www.forbes.com/2003/03/25/cz_dl_0325star2.html
http://www.newscientist.com/article.ns?id=dn7448

A great, aptly-named FPGA site that discusses fun FPGA projects:
fpga4fun.com

Finally, we have a book that vindicates the desirability of a REST interface over AJAX and SOAP.

http://radar.oreilly.com/archives/2008/01/a_year_in_oreilly_books.html,

I remember back when SOAP, UDDI and all the rest of the corporate web services stack was introduced, many people in the open source community saw it as an attempt to recapture the web, making it complex enough to be an enterprise software play. But those complex stacks never caught on.

gives us a whiff of the commercial motives behind the introduction of technologies that override REST.

The quote in http://www.oreilly.com/catalog/9780596529260/index.html,

RESTful Web Services … provides a practical roadmap for constructing services that embrace the Web, instead of trying to route around it.

is a very telling indictment of the philosophy behind these non-REST technologies. They piggyback on top of HTTP but then seek to subvert the core ideas of the web! In a mailing list post from a couple years back, I expressed similar sentiments.

Back when SOAP and Web services were all the craze and Google introduced a SOAP-based API to their Search Engine some years ago, I frankly could not understand what was going on inside their supposedly brilliant heads. A REST-style URL-based interface would have been immensely simpler to learn and would not really have lost any functionality compared to the SOAP-based API. What happened? Google swallowed the “Web Services” Kool-Aid is what. (Some might even say the blame goes all the way back to Dave Winer and wonder why the rather dubious invention that is XML-RPC ever got all the attention it did)

It is quite interesting to discover that even for more demanding applications such as payment gateways, a REST-based approach is still feasible. A Philippines payment gateway, payeasy.ph, eschews a SOAP-based interface in favor of the much simpler GET and this is apparently enough to get things done. Having suffered the hell of interfacing with SOAP-based payment gateways, I couldn’t agree more with their decision and am left wondering why more people have not realized that they can do away with all the Rube Goldberg-style machinery imposed by SOAP (worried about job security perhaps? )