This is inspired by Ian Landsman’s comment:
I think developers are afraid to build components for languages like Perl, PHP, etc because of the risk of an open source competitor but I think there’ s a good business in there someplace.
Off the top of my head, here are some PHP components / libraries / solutions I would gladly pay for:
- As we know, all programs expand until they can read mail ;-) So I would love a library that does exactly that: integrate with mail accounts (supporting pop, imap, exchange, web mail services with no pop access, whatever else exists), retrieve mail, filter it for spam (with keywords, black/white lists and / or Bayesian Filtering), convert from weird / non standard encodings, handle html, detect quoted parts and give it to me in a nice format.
- A special installer for PHP applications. This should probably be based in a well-established installer (e.g. NSIS or InnoSetup) for Windows and something similar for Linux / Unix / MacOS. It should of course support all these Op. Systems. It should detect if Apache / PHP is installed and use it, detect and use IIS on Windows installing PHP if it’s not installed. It should even install Apache / PHP / MySQL on a clean system (if this is allowed by the various licenses of course). Finally it should take care of databases. A mechanism should be provided to install / update the database, at least for the most popular databases (Access, MySQL, MS SQL, Postgres)
- APIs to integrate with other services (which may or may not offer their own API). A good example of a service I would like to integrate with, is Google Maps. The integration of craiglist and Google Maps is an exceptional example of what one can do. Flickr is another service I may want to integrate with. Contrary to Google Maps, they offer a public API, but it requires a lot of work (and that’s why so many 3rd party API kits exist). Search engines (Google, Yahoo) offer APIs but they are incompatible. If I wanted to integrate with them I would have to do a lot of work. Amazon, Feedburner, Bloglines and many others provide APIs, but it’s difficult to integrate with each and every one of them. I would like one API for similar services (one for eShop sites, one for Search engines, one for RSS content, one for News portals etc). I would like the API I use to stay the same, even when the underlying APIs change (e.g. the Flickr API which is in beta changes from time to time).
Of course, if you happen to know any existing solutions for the above (free or commercial), drop me a line.
Yep I second these. Especially the first 2. I’ve already written #1 for HelpSpot and it was a huge pain and one of the areas I’m going to have to do tons of testing in. #2 is also on my list of things to build. As you say I would have happily paid for quality, well tested, components which do those 2 things.
Comment by Ian — June 21, 2005 @ 15:58
And your next sentence after the quote I copied is: “Hmm maybe UserScape product #2?????”. Well, I would certainly consider it, especially with all the work you have (will) put in these two areas. The only downside is that it could be a little hard to support and market for two different markets (business users vs. developers)
Comment by Dimitris Giannitsaros — June 21, 2005 @ 19:13
Yeah, it might be confusing for potential customers of HelpSpot when they wander around the site and find very technical developer oriented products. Also there would be work to get it into that type of shape, because the code is really built into HelpSpot right now and in no way designed for general use. So I’d have to pull out alot of logic and so on, but maybe down the road.
What I’d probably do is take the feedback from v1 HelpSpot users and build a new component for email access from the ground up as a stand alone product.
Comment by Ian — June 21, 2005 @ 20:24
Regarding the APIs, you may want to check http://pear.php.net/
On the other hand, having a common abstraction layer for services like Google, Yahoo, Flickr, etc is not easy -they may seem like they are similar services, but they are not. Compare Google WEB APIs, Amazon Web Services and Yahoo! Search Web Services. (will they ever adopt, http://opensearch.a9.com/ ? I hope so…)
Comment by Panayotis Vryonis — June 24, 2005 @ 12:20
Well there could be API categories. E.g. for all search engines it should just return you results with common attributes (link, title and maybe description). For ehsops it should support a link, description and maybe item category and price.
For instance, if I want to embed search results in my product I would something on the lines of:
$api = new CommonSearchAPI;
$api->initEngine(’Yahoo’);
$api->initEngine(’Google’);
$results = $api->search($keyword);
print_r($results);
Comment by Dimitris Giannitsaros — June 24, 2005 @ 13:09
Very useful comments - good to read
Comment by Anonymous — August 14, 2005 @ 17:23
[...] Some posts by Ian Landsman and Dimitris Giannitsaros confirmed my ideas about this so I decided to give it a go ! [...]
Pingback by New direction at Overview — January 8, 2006 @ 15:00