Flash Communiction Serverと書くと長いし、FCSと略すと短すぎる。帯に短し、たすきに流し感は、FCSの価格戦略あたりにもあらわれていたりして。

FCS自体は間違いなく素晴らしいアイディアのサーバーであるが、そのメリットである肝心のサーバーサイドアクションスクリプトは、非常に書きにくい。
それ自体はJavaScriptの文法で記述するのである。Applicationオブジェクトというアプリケーションスコープのオブジェクトに全体的なルールを記述し、Clientオブジェクトというユーザー一人一人に与えられるオブジェクトを拡張してクライアント毎の機能を実装していくのが基本である。

この時点で、多層的なオブジェクトの構造を成しているわけだが、ソースコードはクラス構造ではなく、ただのJavaScriptで記述するところがややこしい。

基本は、ひたすら上下に書く平面的な記述なので、本気のアプリを書くと間違いなくスパゲティコードになることであろう。（マクロメディアから用意されているFCSフレームワークはあまり理解してないので、そこでどこまで整理されるかはわかってません。）

Java Scriptというのは自由度が高く、ある意味、奥が深い言語で、オブジェクト記述言語としてみると、結構悩ましい言語である。Object型という木の幹になんでもかんでもペタペタ貼り付けられるイメージがあり、自分のイメージとしては、「塊魂」と言ったところ。

変数スコープがメチャクチャな印象がある。ルールが厳密で、きっちりクラスを定義していく秩序ある世界のJavaに慣れていると、この曖昧さ、なんでもあり感は、どうにも落ち着かない上に、わかりにくい。

ソースコードとして、あらゆるオブジェクトが縦に連なって書かれていると、そのオブジェクトが指し示すthisが誰かがわかりにくくなる。その罠に最初に気がつくまで、Java Scriptだからといって安易に考えると苦労することだろう。

そして最も重要なことは、FCSのアプリとはアプリケーションレイヤーでの通信シーケンスの制御コードのため、きっちり設計しないと、何がなんだかわからなくなってしまう。最低限シーケンス図などによる全体的な見通しの設計は必須で、無計画に、ほいほいと思いつくままアプリを作れるわけではないところに敷居の高さを感じる。

だからこそActionScript（Java Script文法）のような形で敷居の低さを演出せずとも、Javaに慣れていて、アプリケーションの設計に慣れている人向けにしてしまって問題ないのではないかと思う。

とはいえ、お気軽にリモートメソッドを書ける感はSOAPの比ではないので、普及の第一歩としては現状を肯定したとして、次期バージョンは、是非ともJavaベースにして欲しい。JRunがJava Scriptエンジンを持っているのだから、もし現在の互換性を維持するのなら、その辺を利用しつつ通常のJavaクラスを連携が取れるようにして欲しいものである。特に外部I/Oへのアクセスがあまりにも貧弱なためJavaで拡張させられるのは重要ではないだろうか。ただ、その時にはリモートメソッドのお手軽間は今のまま残しておいてもらえるとありがたい。