Forward compatibility: Difference between revisions
No edit summary |
No edit summary |
||
| Line 6: | Line 6: | ||
The introduction of a forward compatible technology implies that old devices partly can understand data generated by new devices<ref name=Tulach> [http://books.google.com/books?id=DXYZZVlWOAkC&pg=PA233&dq=forward+compatibility+TV&hl=sv Practical API Design: Confessions of a Java Framework Architect], by [[Jaroslav Tulach]], Apress 2008, ISBN 1-4302-0973-9, ISBN 978-1-4302-0973-7, page 233</ref>. |
The introduction of a forward compatible technology implies that old devices partly can understand data generated by new devices<ref name=Tulach> [http://books.google.com/books?id=DXYZZVlWOAkC&pg=PA233&dq=forward+compatibility+TV&hl=sv Practical API Design: Confessions of a Java Framework Architect], by [[Jaroslav Tulach]], Apress 2008, ISBN 1-4302-0973-9, ISBN 978-1-4302-0973-7, page 233</ref>. |
||
Although forward compatibility and [[extensibility]] |
Although the concepts of forward compatibility and [[extensibility]] are similar, they are not the same. A forward compatible design can accept data from a future version of itself and pick out the "known" part of the data. An example is a text-only word processor ignoring picture data from a future version. An extensible design is one that can be upgraded to fully handle the new data in the newer input format. An example is a text-only word processor that can be upgraded to handle picture data. |
||
A forward compatible system is expected to "[[Graceful exit|gracefully]]" handle input which is intended for a newer version, by ignoring the unknowns and selecting the known subset of the data that the system is capable of handling. |
A forward compatible system is expected to "[[Graceful exit|gracefully]]" handle input which is intended for a newer version, by ignoring the unknowns and selecting the known subset of the data that the system is capable of handling. |
||
Revision as of 04:51, 4 July 2012
This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.
Forward compatibility or upward compatibility (sometimes confused with extensibility) is a compatibility concept for systems design, as e.g. backward compatibility. Forward compatibility aims at the ability of a design to gracefully accept input intended for later versions of itself. The concept can be applied to entire systems, electrical interfaces, telecommunication signals, data communication protocols, file formats, and computer programming languages. A standard supports forward compatibility if older product versions can receive, read, view, play or execute the new standard.
The applicability of a forward compatible system with new versions requires not only the respecting of the older version by the designers of the newer version but additionally some agreement on future design features with the design freeze of current versions. The introduction of a forward compatible technology implies that old devices partly can understand data generated by new devices[1].
Although the concepts of forward compatibility and extensibility are similar, they are not the same. A forward compatible design can accept data from a future version of itself and pick out the "known" part of the data. An example is a text-only word processor ignoring picture data from a future version. An extensible design is one that can be upgraded to fully handle the new data in the newer input format. An example is a text-only word processor that can be upgraded to handle picture data.
A forward compatible system is expected to "gracefully" handle input which is intended for a newer version, by ignoring the unknowns and selecting the known subset of the data that the system is capable of handling.
Forward compatibility is harder to achieve than backward compatibility because a system needs to cope gracefully with an unknown future data format or requests for unknown future features. Backward compatibility does not have this issue because it accepts a known data format.
Examples
Telecommunication standards
The introduction of FM stereo transmission, or color television, allowed forward compatibility, since monophonic FM radio receivers and black-and-white TV sets still could receive a signal from a new transmitter. [1] It also allowed backward compatibility since new receivers could receive monophonic or black-and-white signals generated by old transmitters.
Video gaming
The Game Boy system was forward compatible with most games created for the Game Boy Color. (Clear-colored cartridges however housed games not backward compatible.). The Neo Geo Pocket was also forward compatible with games for the Neo Geo Pocket Color.
Systems architecture
Many application software systems are designed with a robust and self-sufficient systems architecture so that they can operate adequately even when input for a more advanced version is entered.[clarification needed]
In all cases, when the application system accepts the input data or operating system is not as expected, it will produce an output that will identify the problem accurately for the user.[clarification needed]
Document formats
An example of forward compatibility is with a word processor. Assume that Version 1 of a word processor only allows text, and no graphics. It saves files with only information about the text typed, and the font, color, and size of the text. Let's say that the program adds the mark [VERSION1 END] to denote the end of the file. However, next year Version 2 is released that accepts graphics. However, the new word processor saves all of the text at the beginning of the file, puts the [VERSION1 END] mark, and then stores the picture data next, and puts a [VERSION2 END] mark after the picture data. The Version 1 word processor would still be able to read the text data up to the [VERSION1 END] mark, but would ignore the picture data afterward. When Version 3 is released that allows videos in the word processor file, it would save in this format: text data [VERSION1 END], picture data [VERSION2 END], and video data [VERSION3 END].
Adobe Reader / Adobe Acrobat
Although the above file design allows forward compatibility, there are additional features that can be added to be more useful to the user. One would be if Version 1 of a program printed a message that the file was created with a newer version of the software, and that some data was not available. The Adobe Reader program generates a message notifying the user of a PDF file that it was created in a newer version of Adobe Acrobat, and some features will not be available.
MS Word
Another useful feature is if Version 1 of a program offered to download a viewer or converter that allows the user to at least read files from newer versions of the program, even though the user may not be able to edit them. In the above word processor example, Version 1 would download updates from the internet that allows the user to see the pictures and videos in later versions of the word processor, even though the user cannot add, edit, or modify the multimedia data, due to that functionality not being in Version 1. An example of this functionality is Microsoft Word. When a document is created in Microsoft Word 2007 and opened in an earlier version (like Microsoft Word 2003), Microsoft Word 2003 tells the user it can download a converter to read files in the newer Microsoft Word 2007 format. This allows Microsoft Word 2003 to read data created by Microsoft Word 2007, even though the user cannot use Microsoft Word 2003 to build new data in the advanced format.
PNG
An example of forward compatibility is the Portable Network Graphics (PNG) format, which divides data into "chunks", and indicates whether these are "critical" or "ancillary", where ancillary chunks can be ignored by programs that do not understand them.
More subtly, it also indicates whether chunks are safe to copy by readers that do not recognize them – thus ensuring that data does not become out of sync.
See also
References
- ^ a b Practical API Design: Confessions of a Java Framework Architect, by Jaroslav Tulach, Apress 2008, ISBN 1-4302-0973-9, ISBN 978-1-4302-0973-7, page 233