The implicit assumption that the author is making here is that 64-bit CPU's such as Itanium will be the 'next big thing'. I'm not sure - 64-bit CPU's really only are necessary for machines that need more than 4 GB of VM space - and with various x86 addressing extensions, some IA32 CPU's can address up to 16 GB (I think).
Now don't get me wrong - 64-bit filesystems are great, and necessary - being limited to 2GB or 4GB files is terrible. But no 64-bit CPU is necessary for that kind of thing, the filesystem just has to be written as 64-bit (which is easier said than done, and could easily sacrifice backwards-compatibility with various API's, but I digress...).
That being said - Intel might very well be moving down the wrong path - the Itanium is a huge, expensive, hot, completely new chip. Even Intel is hedging its bets on whether or not Itanium will take off - and AMD is poised to eat Intel's lunch with their new Hammer design.
Who knows, perhaps all CPU's from now on will be compatible with x86 IA32, and innovation will be in the various processing units that sit behind the instruction-set decoder. Take a look at AMD or Transmeta for examples of that, already.
The proposal isn't actually a bad one - we're talking about just a simple C library which can read, write, and parse configuration files using 'plug-in' stub libraries. That's what the author of the article is proposing. It strikes me as a good idea for several reasons:
Certain configuration file-formats we're kinda 'stuck' with. For these files, we just have to write the plug-in which can read, write, and parse them. We don't have to re-write the application to comply with The New Way. The app doesn't need to change, or even be aware of the configuration library.
A configuration utility written to use the library would be able to configure all applications which have the appropriate plug-in installed. So if someone writes a nice pretty GUI X-based app, it can configure everything. If someone writes a curses-based text menu app, it can configure everything. A web-based configuration app could also configure everything. Some config-apps could be oriented for gurus, and some could be designed for newbies.
Eventually, applications themselves could use the library to read in their own preferences. Bonus - it's a little easier to write applications now.
All that being said, I foresee some 'gotchas' -
The library system would need to not only know about configuration file formats, but some meta-configuration info such as - application X uses config-file format Y in location Z. Application X can be forced to reread its config by sending it a SIGHUP, it's process name is 'blah'.
The design of the API for the main library has to be made veeeeeeery carefully. The number of different types of data that you'll have to deal with here are huge - we're not just talking 'integer, string, float' - but some relatively complex data structures like IP Address, or 'Firewall mapping' (two IP addresses, two ports, and a UDP/TCP choice).
Configuration file formats that are unbelievably miserable and allow for the user to put script bits in them (isn't this why we all hate MS Word?) would be almost un-programmatically-configurable. Sendmail.cf comes to mind. It gets to the point, there, where the only thing that's ever going to understand the config file is the application itself.
Shouldn't the 'boss' character either be giving less detailed requirements, or just choose the language him/herself?
My gut instinct is that if someone has such a strong idea of what is required, and has such detailed specifics, that that person is just a few tiny steps away from the final decision anyways.
Either that, or the PHB just put every single programming buzzword into the requirements document to sound 'cool'.
Slashdot Mirror
Now don't get me wrong - 64-bit filesystems are great, and necessary - being limited to 2GB or 4GB files is terrible. But no 64-bit CPU is necessary for that kind of thing, the filesystem just has to be written as 64-bit (which is easier said than done, and could easily sacrifice backwards-compatibility with various API's, but I digress...).
That being said - Intel might very well be moving down the wrong path - the Itanium is a huge, expensive, hot, completely new chip. Even Intel is hedging its bets on whether or not Itanium will take off - and AMD is poised to eat Intel's lunch with their new Hammer design.
Who knows, perhaps all CPU's from now on will be compatible with x86 IA32, and innovation will be in the various processing units that sit behind the instruction-set decoder. Take a look at AMD or Transmeta for examples of that, already.
- Certain configuration file-formats we're kinda 'stuck' with. For these files, we just have to write the plug-in which can read, write, and parse them. We don't have to re-write the application to comply with The New Way. The app doesn't need to change, or even be aware of the configuration library.
- A configuration utility written to use the library would be able to configure all applications which have the appropriate plug-in installed. So if someone writes a nice pretty GUI X-based app, it can configure everything. If someone writes a curses-based text menu app, it can configure everything. A web-based configuration app could also configure everything. Some config-apps could be oriented for gurus, and some could be designed for newbies.
- Eventually, applications themselves could use the library to read in their own preferences. Bonus - it's a little easier to write applications now.
All that being said, I foresee some 'gotchas' -Shouldn't the 'boss' character either be giving less detailed requirements, or just choose the language him/herself? My gut instinct is that if someone has such a strong idea of what is required, and has such detailed specifics, that that person is just a few tiny steps away from the final decision anyways. Either that, or the PHB just put every single programming buzzword into the requirements document to sound 'cool'.