こんにちは。

Japan SharePoint Group にご参加いただいた皆様、またまた時間オーバーで申し訳ありませんでした。(PC を 2 台用意していたのですが、結局、1 台はまったく使いませんでした. . . キャリーバックの意味なし)
次回以降 (東京開催) も、可能な限り、参加させて頂きたいと思いますので、よろしくお願いします。

セッションで紹介 (というか、推奨) させていただいた SharePoint における JavaScript 開発について、かなり言い足りない部分がありましたので、以下に補足しておきます。

REST (listdata.svc) or SOAP (.asmx) ?

jquery による ajax 接続を使って SharePoint のデータ (情報) と連携させる方法として、REST Web Api (listdata.svc) を使う方法と、SOAP Web Services (.asmx) を使う方法があります。
これから開発される方のために、これらの長所 (Pros)、短所 (Cons) を以下に簡単にまとめておきます。

• jQuery を使用して開発する場合、言うまでもなく、SharePoint の REST Web Api を使用したほうが、格段に相性が良くなります。
  例えば、jQuery の DataTables プラグインを使って、受け取ったデータを table にロードする場合を想像してみてください。データは、JSON フォーマットであることを前提としているため、SharePoint SOAP Web Services や JavaScript OM (Client.svc) などで受け取ったデータ形式では、こうした plug-in との相互利用がむずかしくなります。(受け取った XML の内容などをパースする必要があります。)
• なお、SharePoint の REST Web Api を使用する場合、ご存知の通り、取得可能なデータ数の上限があるので、大量データを扱う場合には、ページング (つまり、OData の $top、$skip を使った呼び出し) を有効活用してください。
  SharePoint の REST Web Api は OData に対応しているため、datajs を使った Prefetch 処理など、データ抽出の高速化も可能です。
• SharePoint の REST Web Api を使用した場合、短所 (デメリット) もあります。まず 1 つ目が、可能な処理に限界があるという点です。
  SharePoint の REST は、List リソースに対する CRUD 処理のみが対象となっているため、例えば、リストに関する詳細情報の取得、高度な検索 (ただし、リスト アイテムのクエリーは可能です)、ワークフローの制御など、それ以外の処理では、SOAP Web Services (.asmx) か JavaScript Client OM (Client.svc) を使う必要があります。(特に、SharePoint の SOAP Web Services は、SharePoint Designer からの接続など SharePoint 内部でも使用されており、非常に広範囲な操作が可能です。)
• あと、セッションでも説明した通り、SharePoint の REST Web Api を使用する場合に遭遇する問題として、SharePoint の REST で取得する entity 名 (Url, Title) は、厳密なリストの名前 (List Name) と異なっているという点です。(空白文字は削除され、先頭文字や、空白文字の直後の 1 文字目は、大文字に変換されます。)
  このため、例えば、リストの名前をもとに、対象の REST Web Api を呼び出す場合は、専用の変換処理などをおこなう必要があります。また、リスト名の一覧を取得する際なども、正確な名前の取得には SOAP Web Services を使用する必要があります。(また、そのリストが、ドキュメント ライブラリーかどうか、といった判定も、SOAP Web Services を使ってください。)
• SOAP Web Services を使用した場合の短所 (デメリット) は前述の通りです。(例えば、さまざま jquery plug-in などとの親和性がない、など。)
  また、この他にも、当然、jQuery で SOAP Web Services の呼び出しをおこなうと、コードが煩雑になる (可読性の低下) といった短所 (デメリット) もあります。(jQuery の ajax の記述は、REST 呼び出しを前提に最適化されています。) このため、SOAP Web Services を使った主要な処理は、カスタムの function や、カスタムの jQuery plug-in (つまり、.js ファイル) として まとめておくなど、配慮が必要です。
  なお、こうした SOAP Web Services の呼び出しをライブラリー化した Open Source として、CodePlex の SPServices (jQuery Library for SharePoint Web Services) という plug-in も提供されています。

なお、SharePoint の REST Web Api は、JSONP には対応していません。(仮に、構成 (.config) 変更で対応できたとしても、データの性質上、おすすめしませんが . . .)

配布方法に関する留意点

ライブラリー (.js ファイル) のスクリプト参照 (<script> タグ) や、カスタムの .js ファイルの配置方法について、留意点を記載します。

• ライブラリー (.js ファイル) のスクリプト参照 (<script> タグ) について、思いつく方法として、MasterPage や ASP.NET ページ (.aspx) に、直接、スクリプトの参照 (ScriptLink) を記述してしまうかもしれません。しかし、メンテナンスの観点から、ScriptLink を使った CustomAction (<CustomAction> タグの ScriptSrc 属性) としてパッケージ (.wsp) に含めておくと良いでしょう。
  SharePoint のソリューションでは、この ScriptLink を使った CustomAction を使うことで、機能 (feature) の追加や削除に際して、関連するスクリプト参照をまとめて管理することができます。
• また、.js ファイル (jQuery ライブラリーなど) の配置先ですが、パッケージ (.wsp) の機能 (Feature) の 1 つとして、専用のリスト インスタンス (カスタムのドキュメント ライブラリー) を構築し、ここに、モジュールとして .js ファイルを配置 しておくと良いでしょう。(こうすることで、.js ファイルと、それを使う機能の管理が容易になるためです。なお、いずれも、サンドボックス ソリューションとして構築できます。)
  サイボウズさんが構築された CodePlex 上のサンドボックス ソリューション などは、まさにこの方式で配布されているので参考にしてみてください。
• もう 1 つの配布方法として、CDN (Contents Delivery Network) を使用する方法があります。
  特に jQuery ライブラリーなど汎用的なライブラリーでは、複数の独立した機能 (feature) で同一の .js ファイルを使用する可能性が高いため、CDN を使うことで、再利用による効率化と、管理の簡素化が期待できます。ただし、CDN を使った場合、オンプレミスの SharePoint など、インターネットに接続されていない企業環境などでは、ライブラリーが使用できない結果となるので注意してください。
  なお、開発者が作成したカスタムの .js ファイル (上述したカスタムの plug-in など) も、WIndows Azure の CDN を使って配置できます。

この他に、これは SharePoint に限ったことではありませんが、カスタムの JS ファイルの開発や配置に際しては、Minification (空白の削除などによる消費リソースの最適化) などにも配慮してください。
(ScottGu も書いている通り、ASP.NET 4.5 では、このあたりのチューニングが大変やりやすくなっています。ただし、残念ながら、SharePoint 2010 は .NET Framework 3.5 ベースのため、この手法は使えません . . .)