問題タブ [backwards-compatibility]

HTTP サーバー/クライアントを作成するとします。HTTP/1.0 をサポートすることはどれほど重要ですか? 今でもどこかで使われていますか？

編集: HTTP/1.0 の有用性/重要性についてはあまり関心がありません。むしろ、実世界 (ブラウザー、ロボット、スマートフォン/愚かな電話など...）。

例えば：

私は両方を見てきました。_T は簡潔にするため、_TEXT は明確にするためのようです。これは単に主観的なプログラマーの好みですか、それともそれよりも技術的なものですか? たとえば、一方を他方の上に使用すると、コードは特定のシステムや古いバージョンのヘッダー ファイルに対してコンパイルされませんか?

UniData 7.1 で Basic Developer Toolkit を実行する人はいますか?

IDE は UniData 7.2 でリリースされましたが、7.1 でも問題なく動作するという印象を受けました。ただし、アカウントで「データベース ファイル」を開くと、すべての単一の DIR タイプ ファイルで読み込みエラー ダイアログが表示され、レコードが登録されません。

IDE が 7.1 で動作する前に UniData サーバーに変更が必要ですか、それとも何か別のことが進行中です。私の知る限りでは、UniObjects for Java を使用して UniData RPC デーモンと通信しているだけなので、通信に問題はありません。

まともなIDEで作業するのはいいでしょう...

IPCライブラリを使用する場合、APIのバージョンが異なっていても、クライアントとサーバーの両方が通信できる可能性を提供することが重要です。クライアント/サーバーアプリケーションにSOAPを使用することを検討しているので、SOAP/WSDLソリューションがAPIの変更をうまく処理できるかどうか疑問に思います。

例えば：

• 既存の関数へのパラメーターの追加
• 既存の関数で使用されている既存の構造体に変数を追加する
• 機能の削除
• 既存の関数からのパラメーターの削除
• 既存の関数で使用されている既存の構造体から変数を削除する
• 既存の関数で使用されているパラメーターのタイプを変更する
• 既存の関数のパラメーターの順序を変更する
• 既存の構造体の複合パーツの順序を変更する
• 既存の関数の名前を変更する
• パラメータの名前を変更する

注：「構造体」とは、複合型を意味します

HTML5のcanvasタグまたはvideoタグをサポートしていない古い/現在のブラウザのHTML5のように動作させるためのjavascriptソリューションはありますか？

キャンバスタグは、HTML5をサポートするブラウザの場合と同じように動作するのが理想的ですが、ビデオタグは、代替コードに置き換えた場合にも適しています。

MVC2アセンブリを使用してMVC1アプリケーションを問題なく実行できますか？一部のサードパーティツールがMVC2で壊れていることを理解していますが、他のツールを使用していないと仮定しましょう。

このプロジェクトを実行していますが、プログラムの問題があります。

ウィンドウ 98 で動作する「C」言語に基づくプログラムを選択しました。

しかし、このプログラムをウィンドウ 7 で実行する必要があります。同じプログラムが実行されるでしょうか。そうでない場合は、どうすればよいですか。

VisualStudio2010はMVC1.0と互換性がありますか

こんにちはみんな、

よろしくお願いします。

私はMVC1.0プロジェクトとVS2008を使用しています。

VS2010にアップグレードできてとてもうれしいですが、MVC1.0との互換性については疑問があります。

あなたはそれをしましたか？その結果はどうでしたか？

私はネットワーク監視アプリケーションに取り組んでおり、どのバージョンの SNMP が他のバージョンと下位互換性があるかを知る必要があります。Java でプログラムを作成し、SNMP4J を使用して特定のデバイスの OID を照会しています。SNMP4J 内では、ターゲットを設定するときに SNMP デバイスのバージョンを指定する必要があります。

現在、SNMP バージョン 1、2c、および 3 があります。SNMP バージョン 1 のデバイスを使用している場合、SNMP バージョン 2c または 3 はそのバージョンと下位互換性がありますか?

デバイスがバージョン 2 の場合、1 または 3 は下位互換性がありますか?

... 等々

とにかく、すべての助けは大歓迎です、

スティーブ

I'm interested in what strategies people have come up with for separating all the crufty logic that's necessary to maintain backwards compatibility from the main code of an application. In other words, strategies that let you come closer to having your code look as if there were no backwards compatibility concerns except for separate isolated source files distinctly for that task.

For example, if your application reads a particular file format, instead of one giant honking file parsing function, you could have your code first iterate a list of "quirks" entries/objects, where each quirk checks the file to see if it's a file it would apply to, and if so invokes its own parsing logic instead of the normal case logic.

Quirks is an OK strategy but you have to do work to put hooks in for quirks checks at all the appropriate places in your app, and what the checks will look like will vary for different quirk types, etc. It almost seems like there should be libraries dedicated to the boilerplate for this task. Another issue is how to enforce that quirks aren't abused as general purpose hooks into arbitrary chunks of the app.