One thing that keeps coming up in this discussion is the issue of "being tied to an API we don't control".
People... We're *fantastically* privileged that we get to define an API of our own. Lots and lots and lots of people and projects spend all their time implementing existing (open, but completely static) protocols and specifications. Every HTTP, SMTP, and IMAP server on the planet does it. Every single C compiler on the planet does it. All of these are things that have been defined a long time ago. You can have all the opinions you want about IMAP, but that doesn't mean you can just implement it differently. At least not if you expect people to support your stuff. When there are ambiguities in the spec, sure, you can insist on taking one path even though everyone else has taken a different one, but don't expect the rest of the world to change to accommodate you. If you want to do offer something better by doing something differently, offer it as an alternative that people can switch to once you've won them over. Don't make it a prerequisite. There's a golden rule when implementing things according to an existing specification: Be very conservative in what you deliver, and be very liberal in what you accept. Otherwise, people. will. use. something. else. period. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
