Markus Schaber <schabi@logix-tt.com> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> Alexander Bartolich <alexander.bartolich@gmx.at> writes:
>> > Markus Raab schrieb:
>> >> icheck (ein API checker) meldet mir wenn ich einen Enumerator hinzufüge dass
>> >> das API nicht vorwärts-kompatibel ist[0].
>> >
>> > http://en.wikipedia.org/wiki/Forward_compatibility
>> > # Forward compatibility (sometimes confused with extensibility) is
>> > # the ability of a system to gracefully accept input intended for
>> > # later versions of itself.
>>
>> 'icheck' ist ein Debian-Utility und die man page definiert 'forward
>> compatibility' als 'things compiled against the old version will work
>> with the new' und 'backward compatibility' als 'things compiled
>> against the new version will work with the old', also genau umgekehrt.
>>
>> Das scheint mir auch etwas sinnvoller als der von Dir zitierte Text,
>> denn ein solches 'vorwaertskompatibles System' kann es gar nicht
>> geben, weil es schlicht unmoeglich ist, Eingabedaten in einem
>> unbekannten Format als gueltige Eingaben zu akzeptieren. Bestenfalls
>> kan man unbekannte Teile einer zusammengesetzten Nachricht ignorieren
>> und hoffen, dass das, was sie an scheinbar bekanntem enthaelt, auch
>> alleine noch einen Sinn ergibt.
>
> Ich kann mich erinnern, früher mal in einem Projekt IDs gehabt zu haben,
> in denen ein bestimmtes Bit festgelegt hat, ob man unbekannte IDs
> ignorieren oder einen Fehler melden soll.
>
> Ein weiteres Beispiel sind die Metadaten in jpegs oder MP3s -
> unbekannte Chunks können ignoriert werden (z. B. GeoTagging oder
> Plattencover als Bild), das Bild kann man trotzdem anzeigen, und den
> Song trotzdem abspielen.
Was soll das in dem gegebenen Kontext jetzt bedeuten? Es gibt
sogenannte 'erweiterbare' Datenformatdefinitionen, die aus einer
urspruenglich definierten Basismenge von Eigenschaften bestehen, sowie
einem Erweiterungsmechanismus, der es ermoeglicht, Informationen so zu
einer 'Nachricht' in diesem Format hinzuzufuegen, das
Implementierungen, denen lediglich das 'Basisformat' bekannt ist, den
'Basisformatsteil' einer solche Nachricht benutzen koennen, ohne sich
um ihnen unbekannte Erweiterungen des Formats kuemmern zu
muessen. Dafuer ist allerdings die 'zeitliche Reihenfolge' von
Erweiterungsdefinition und Implementierun uninteressant -- zB koennte
man heute ein TCP-Modul implementieren, dass die
die RFC793-Teile TCP versteht und alle spaeter definierten Optionen
bis auf SACK ignoriert. Dieses 'erweiterte Feature' koennte man jetzt
in einer von dem urspruenglichen Code abgleiteten 'anderen
Implementierung' auch noch entfernen und beide mit einem (viel
aelteren) Linux-2.4-TCP sprechen lassen, dass selective
acknowledgments benutzt. Was ist hier jetzt warum vorwaerts- oder
rueckwaertskompatibel wozu? Oder was genau bedeutet 'spaetere Version
von sich selbst?', ausser 'in der Zukunft entwickelte anderen
Software' (die mehr oder minder zufaellig einen Teil des Quellcodes
mit der aelteren gemein hat, was ein Implementierungsdetail waere).
Re: enum API Kompatibilität 
Linear Mode
