|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|News||OFM Book||Orthodox File Managers Standard 1999(OFM1999) - basic OFM requirements||The Orthodox File Managers Standard 2004(OFM2004). Advanced OFM requirements||The Orthodox File Managers Standard 2012(OFM2012) -- Cutting Edge Features of Orthodox File Managers||Less is More: A rich functionality behind Spartan interface of Orthodox File Managers|
Standards are often created in non-standard way, and often, de facto standard long precede the official one. Such de facto standard often has a form of "reference implementation". That what happened with OFMs where Norton Commander, especially NC 3.0 and 5.5 and then Volkov commander, FAR and Total commander were the "source of inspiration" for many independent OFM developers on Windows. On Unix the most influential reference implementation other then Norton Commander 3.0 and 5.5 was Midnight Commander.
Reasonable people can disagree which elements of the standard are important and which are not. Programmers can always try to take an advantage of the ambiguity of specification, but adhering to the standard makes learning for the users less painful and makes migration of substantial percentage of user to better implemented, better supported OFMs a possibility (actually this was always the main advantage of OFM paradigm).
Still overcomplexity of the current computing environment make the question "When enough is enough" very important and very difficult to answer. Removing from the standard dead wood increases chances of its adoption by best products as any standard creates an implicit pressure for developers to comply with minimal requirements (see OFM1999). Pressure that exists even when many of them never read the standard ;-). But some of their users did.
This is a third revision of the standards. Original (version 1) was published in Jan 1998 (see OFM Bulletin 1998). Version 2 was published in 2004 (when OFM2004 was added and OFM1999 substantially revised). The last revition was made in 2012. At this I three new versions were published
Due to the problem of overcomplexity, "excessive zeal" in defining such any standard can backfire, so I am not in a hurry expanding those three with additional features for at least the next five years ;-). Actually this my foray into "standard creation" activity (which to say frankly is a very complex and underappreciated job). at least gave me some appreciation of the difficulties involved in creating a viable standard. In a way good standard should anticipate future and this is a very difficult task.
Of course today computers are tremendously more powerful then in 1999 when the first standard was created so some features excluded can be added and some limitations relaxed. But complexity of codebase for a good OFM implementation is now really "neck-breaking" and codebase for OFM on a compiled language can easily exceed 100K lines. That's probably why leaders did not change (we have FAR, Total Commander and MC as three leading implementations -- the same as we have in 1998 when the version 1 of OFM 1999 was published). This is also why standard 2004 (advanced OFM requirements) proves to be a way too complex and for the last seven year the progress toward meeting those requirements in existing OFMs was very slow. As of 2012 I do not think that it is feasible to measure the compliance with this standard the way I do it for OFM1999.
FAR integrated LUA in version 3.0, Total Commander now have multiple panels and horizontal positioning and Midnight Commander has better implementation of full shell terminal window and improved built-in editor. That's about it. Among contenders only WinSCP supports scripting. There are a couple of pilot Python-based implementations, but how far they might go within the limitation of a single-developer model is unclear...
In any case five years "revision period" adopted from the very beginning proved to be reasonable and I do not plan return to another revision before 2017. May be even longer "cool down" period would be beneficial before the next revision (the period between 2004 and 2012 revisions was actually more then five years ;-).
As with everything 80% return on implementing set of features can be achieved by implementing 20% of those features ;-). This paradox is true even for OFM1999...
To summarize the current stat of OFM standardization activity we can state that two standard are currently available, and one is under development:
For example you can't put two command in the line separates by semicolon
Last modified: September, 12, 2017