Adobe AIR の Linux 用アルファ版がリリースされました。（Adobe AIR for Linux@Labs） アルファ版ですのでまだバグもたくさんあると思いますがよろしければお試しください。Mac 版 Win 版と同様に英語版になります。
サポートされる環境は以下のとおりです。
Linux Distribution：
デスクトップ環境：
パッケージ管理：
ウインドウマネージャ：
その他詳細はリリースノート （英文） をご覧ください。Linux 版の日本語版に対する要望があれば是非お知らせください。
Flash CS3 および Flash 8 関連のセキュリティ情報が公開されました。（Flash CS3 Professional、Flash Professional 8およびFlash Basic 8における潜在的な脆弱性）
Windows 版に fla ファイルを利用した攻撃に悪用できる脆弱性が見つかったという報告です。怪しい fla ファイルを受け取ったら開かないよう注意してください。この問題は時期メジャーリリースで修正予定とのことです。
ソケットポリシーについて書こうと思っていたら既にちゃんとした記事が公開されていました。
ので、ここではごく簡単に。
ソケットポリシーファイルは Flash Player 7 の時に導入された機能で、XMLSocket や Socket を使った接続要求に対して、サーバ側でアクセス制御を行うための手段として使用されます。
ソケット経由の接続ポリシーに関して Flash Player 9.0.115.0 から変更された主要な点は、１．マスターポリシーファイルの導入、２．メタポリシーのサポート、３．より厳格なソケットポリシーの採用です。9.0.115.0 では、これらを満たしていない環境を警告として扱いますが （デバッグプレーヤだと警告メッセージをログにを出力できます） 来月のアップデート版以降はエラーとして扱うようになります。
とりあえず対処するには、以下のような内容を TCP のポート 843 から返すプログラムをサーバ上で実行します。allow-access-from タグ内の domain と to-ports 属性には実際の環境に合わせて適当な値を設定してください。
<cross-domain-policy> <site-control permitted-cross-domain-policies="master-only"/> <allow-access-from domain="mysite.com" to-ports="999,3050-3052/> </cross-domain-policy>
さて、以下もう少しだけ詳しい説明です。
メタポリシーは、昨年 12 月に発表された Flash Player セキュリティ関連の変更点のひとつです。 メタポリシーに間しては 4 月のセキュリティアップデートでの変更が行われないため、まだ対応しなくても直ぐに問題になることはありませんが、いずれ必須になることは明言されていますので早めに対応しておいたほうがよいかと思います。
さて、メタポリシーはサイト管理者がポリシーファイルを管理するための手段として提供されています。たとえば、管理者の知らないところで勝手にポリシーファイルを定義してアクセス許可を与えるといった状況を防ぐのに使えます。
メタポリシーはマスターポリシーファイル内に記することができます。マスターポリシーファイルはサイトのルートに置かれたポリシーファイル （/crossdomain.xml） です。マスターポリシーファイル内には今までどおり通常のポリシーも記述することができます。メタポリシーの記述には site-control タグを使用します。下はマスターポリシーファイルの例です。
Flash Player のセキュリティアップデートが来月予定されている旨の情報が US のサイトに公開されました。（Preparing for the Flash Player 9 April 2008 Security Update）
このアップデートは純粋にセキュリティ改善を目的としたもので、新機能は一切ありません。しかし、デフォルトポリシーの変更などが行われるため、既存のコンテンツの中には動かなくなるものが出てくることも予想されます。
今回、事前に情報が公開されたのは、この変更に事前に準備する期間を確保するためです。以下、変更点の概要を説明しますので、影響を受けると思われるコンテンツがある場合は対応をご検討ください。
ちょっと間が空きましたが、BlazeDS を使ったサーバからのプッシュ 3 つ目の方法です。
３．Polling + Piggybacking （使用するチャネル： AMFChannel）
この方法は、昔ながらのポーリングをベースにしています。基本的には、サーバにデータの有無を確認するポーリングリクエストを定期的に繰り返し送信することでサーバから最新の情報を取得します。
それに加えて、ポーリング以外のタイミングでサーバへのリクエストを送信する際にも、そのリクエストにポーリングリクエストを付加して送信します。するとサーバは元々のリクエストに対するレスポンスに加えて、ポーリングへのレスポンスがあればそれも一緒に返します。（このように抱き合わせで送信することを指してピギーバックと呼んでいます）
さて、ポーリング＋ピギーバッキングの設定例です。
引き続き BlazeDS を使ったサーバからのプッシュ機能の設定のご紹介です。
２．ストリーミングチャネルの使用 （使用するチャネル： StreamingAMFChannel）
この方法では、クライアントが HTTP リクエストをサーバに送ってクライアント・サーバ間の接続を確立すると、サーバはその接続をデータプッシュ専用のチャネルとして張りっぱなしにします。サーバからのデータは HTTP 1.1 の Transfer-Encoding: chunked を使って送信されます。（そのため HTTP 1.0 クライアントはこの方法が使えません）
ロングポーリングではサーバがデータをプッシュする度にクライアントは新しいポーリングリクエストを送りなおす必要がありましたが、ストリーミングチャネルでは一度リクエストが送られると後はサーバからのプッシュのみ繰り返しになります。ポーリングによるオーバヘッドが無いことや、より遅延の少ないデータ配信が可能であることはこの方法の利点と考えられるでしょう。
下はストリーミングチャネルの設定例です。
Flex 3 と一緒に BlazeDS がオープンソースプロジェクトとしてリリースされました。BlazeDS は RPC とサーバからのプッシュを実現するためのサーバ側のテクノロジーです。クライアント側は Flex 3 のライブラリを使用します。
BlazeDS のプロジェクトサイト（http://opensource.adobe.com/wiki/display/blazeds/BlazeDS） には GNU LGPL 下で turnkey （Tomcat 付き構成済みバイナリ）、バイナリ、ソースの 3 種類のリリースバージョンが公開されています。
また、Adobe のバグ管理サイトにも BlazeDS 用のバグデータベースが追加されました。（http://bugs.adobe.com/blazeds/） 例によって、日本語表示を選択することが可能です。
BlazeDS と Flex （もしくは AIR） アプリケーションの接続にはチャネルの指定が必要です。RPC の利用には LCDS でもおなじみの AMFChannel または HTTPChannel 等を使用しますが、サーバからのプッシュにはこれらに加えて StreamingAMFChannel やStreaminｇHTTPChannel 等が使用できます。
（チャネル名に含まれる AMF と HTTP による違いは送信するデータフォーマットがバイナリ形式かどうかだけなので、この記事では AMF のみ取り扱います）
さて、BlazeDS でのサーバからのプッシュの実現は、3 種類の方法から選択することができます。以下、それぞれの特徴について簡単に説明します。
