Interoperability is Overrated
While drinking my coffee this morning I caught up on my PHP Architect mag (yes, I am 3 months behind). The interesting bit was Marco’s rant on the “insurmountable” difficulties in code interoperability. One of the examples was why we can’t use WordPress plugins inside Serendipity.
The fact of the matter is that it’s not such a big deal. Porting a plugin from WordPress to Serendipity is usually trivial, and as we see more web-services based plugins (stuff like the awesome askimet) the task becomes simpler and simpler.
Interoperability is overrated, the more you think of it the more complex it gets. As you start throwing in new factors into the equation (how will this interoperate with a java/c# application) you start to develop monsters like JSR 170 which solve a lot of problems on paper, but in reality are too unwieldy to be truly useful.
My steps to interoperability are pretty much the same as steps to writing good code.
- Use as much abstract code as possible: Most problems have already been solved in stand-alone PHP packages such as those found in PEAR or Zend Framework. These are (mostly) solid and (mostly) well tested solutions, use them!
- Create new libraries to encapsulate new functionality: If you need to add some complex functionality, create and publish a reusable library which encapsulates the functionality. This will make your work not only simpler to interoperate with other applications, but also enable your code to function in scenarios you may never think of.
- Keep your “glue code” as simple as possible: When it comes to the proprietary code which glues all your pieces together, keep the probability of someone porting the code to another platform, and stay as simple as possible.
- Use services: Whenever possible make your application available as a webservice. This will offer a level of interoperability that is available to any application regardless of shape, size and programming language.
6 Comments »
RSS feed for comments on this post. TrackBack URL
While I agree that in the Java world, it is sometimes taken too far, I do really believe that a central, standard location for specifications such as Java has implemented it would benefit the PHP Community. You don’t need monster documents, just simple, clear specifications of certain API standards. A standard plugin API for weblog applications or forum software, for instance, would be a great benefit. You develop a plugin, and without any refactoring or altering, it will work just as good in your WordPress as it will in Textpattern, Serendipity, Geeklog, Drupal, and whatever other package. Provided, of course, that these packages all implement the API. But I think it would be in their advantage as well.
I think the only organization in the community with enough power and credibility to actually get this off the ground would be Zend, unless there is a strong power from the user community of course. I’d be very willing to work with others to get something like that off the ground.
Sometime the benefit is indirect.
For example, we’ve all had it beaten into us to write Java so that any database calls are platform neutral. We do it by either containing away JDBC code into its own little corner, putting SQL in property files, or by using ORM tools like Hibernate or iBatis.
The rationale is that you should be able to change database implementations with little pain. Sounds good, right? But when was the last time you changed DB implementations? ever?
What is the indirect result? We get better code quality. Our software has better structure and maintainability.
We see the same result when designing code to be interoperable. Even if no one tries to use it, the quality can be improved by the intent.
This is an area where the TDD (test driven development) types hit the nail on the head. By making code easy to test, the code becomes easy to use.
interopability cant be overrated.
wanna go back to the hell the lock down of being stuck in cobol on their main frames caused about all major companies ?.
If you dont abstract information availability from platform and language dependencies you have to pay for it 10 times over later on.
problem is people think in their little box, not expecting their project to ever need to be integrated with other stuff in the future, esp if the orig coders are not around anymore and the technologies are old and the competence to use them is no where to find.
or lets move back to binary protols over TCP where you must take care of platform byte ordering etc ?.
Gustav, if you want to be the one to create the tcp/ip of programming languages, feel free.
You’ve actually made my point, to get the most interoperability you need the most complex code. Assembly or TCP/IP are very good examples. They are both VERY portable technologies but very few people actually interact with it directly, they use less interoperable interface which offers defined interfaces to the abstract interface offered by the level below it. For tcp/ip it would be the OS sockets layer, for assembly it would be C or C and then PHP as in the case with interpreted languages.
You can try to define the ultimate interface, and unless absolutely everyone else jumps on your band-wagon, you’ll be writing code which is just as uninteroperable as the next guy.
In my humble opinion, the best is to stick with web standards and follow the steps outlined above to create a kickass application which is usuable, fast and reasonably extendable.
Aaron Wormus’ Blog: Interoperability is Overrated…
…
Заметил такую тенденцию, что в блогах поÑвилоÑÑŒ много не адекватных комментариев, не могу понÑÑ‚ÑŒ, Ñто что кто то Ñпамит так? Рзачем, чтоб падлу комуто Ñделать))) Имхо глупо…