Plurchase is just a reverse HTTP proxy server looking for an application. It's not too hard to do something similar in perl. 1) start off by downloading a copy of CGIProxy: http://www.jmarshall.com/tools/cgiproxy/ 2) Setup an apache server running CGIProxy 3) Hack the interface box at the top of the screen to include: facebook integration, a meebo chat box, etc... The problem is that this sort of thing tends to _real…
Also, you might notice that you can't ignore all images & static assets, some of the image requests actually modify cookie information so you may need some different level of proxying there -- same goes for css/javascript assets. You'd be surprised what websites do under the cover. Even with all of our technology, there are still some sites that don't function properly and may require some tweaking on our proxy engine. I tested kayak.com yesterday on our proxy and it almost works but there are still some weird issues going on that I'll have to debug further. I mentioned most of these details in a blog post -- had this been the web 1.0 days, proxying might actually be easy, but we wouldn't have the speed of modern javascript interpreters.
I agree with you on some of the ToS stuff that we'd have to potentially work with merchants on. And since we're white-labeling based on domains, we can remove them if they don't want us there, but proxying shopping sites is unlike other sites -- they want customers to buy stuff. Anything that causes a customer to convert better is in their best interest. Large merchants were actually interested in this, but they didn't want partnerships until they saw traction.