SCHEDULE/2.0 /*------------------------------------------- Last Modified:20040402 -------------------------------------------*/ この文書は未だ開発者版です。予告なくごっそり変更される可能性があります。 ■設計思想 ・スケジュールセンサの国際化対応。 ■影響評価 requestエクスポート関数新設、国際化対応系の整備のみで、動作自体に影響はない。 ■DLLエクスポート関数群 extern "C" __declspec(dllexport) BOOL __cdecl load(HGLOBAL h, long len); extern "C" __declspec(dllexport) BOOL __cdecl unload(void); extern "C" __declspec(dllexport) HGLOBAL __cdecl getversion(long *len); extern "C" __declspec(dllexport) HGLOBAL __cdecl request(HGLOBAL h, long *len); ☆Borland系C/C++コンパイラでは_loadのように頭にアンダースコアがつくようですがそちらにも対応した方が良いでしょう。 ☆HGLOBALを返す関数では、C言語のゼロ終端を考慮する必要はありませんが、互換性確保のためゼロで終わったほうが良い？ load 読み込み時にコールされます。HGLOBALにDLLの入るディレクトリのパスが入ります。 GlobalAlloc(GMEM_FIXED,xxx) されたものなのでそのままポインタ(char *)にキャストして利用してください。 また、必ずDLL側でGlobalFreeしてください。 return - 常にtrue　規定ではロード失敗時にfalseですが、falseを返しても何も処理されません。 unload DLL開放直前（＝SSP/CROW終了時＋上書きインストール時、DLL_PROCESS_DETACH前）にコールされます。 return - 常にtrue　規定では開放失敗時にfalseですが、falseを返しても無視されます。 getversion バージョン情報のチェックのために呼び出されます。 load/unloadが未呼び出しの状態でもきちんと動作する必要があります。 lenに返すテキストの長さ（SCHEDULE/2.0＝12文字） 返り値には12バイト以上GlobalAllocしたものにSCHEDULE/2.0というASCII文字列を代入します。 request ロード・アンロード以外の処理はすべてここで行われます。 注意事項はloadと同じです。 return - 下記プロトコル説明のとおり レスポンス用の返り値HGLOBALも、GlobalAlloc(GMEM_FIXED,xxx)で確保されたものにしてください。 ■リクエスト規定 典型的なリクエスト例は以下のとおりです。 GET SCHEDULE/2.0[CRLF] ID: geturl[CRLF] Charset: UTF-8[CRLF] Reference0: 2004,4[CRLF] [CRLF] ※[CRLF]＝CR+LF 空行で終了。Zero-Terminateとは限らないので注意してください。 PLUGIN/2.0のフォーマットは基本的にSHIORI/3.0仕様に準じています。 イベント識別子のIDヘッダと、任意の数(8以降あり)の追加情報であるReferenceヘッダから構成されます。 Referenceの内容はIDによって変わります。 Reference等の内容に改行等を含めたい場合、また含めなければならないと規定したい場合は、%8f%73のように、 回避したい文字のみURLエンコードして渡すよう規定することを *強く推奨* します（仕様ではありませんが） スケジュールセンサ仕様は常にGETです。常に値を返してください。 200以外のレスポンスは全てエラー扱いとなります。 ID - getversion レスポンス Value：バージョン情報 必ずロード直後に呼ばれ、スケジュールセンサの情報を要求してきています。 Valueヘッダでスケジュールセンサのバージョン情報を返してください。 （例：ScheduleSensor/1.0） この時Charsetヘッダも同時に返すと、以降そのCharsetでリクエストが来るようになります。 ID: geturl リクエスト Reference0：西暦年,月,日 Reference0で指定した日付のスケジュールを取得します。 「日」を考慮せず月一括取得の場合（現在の実装）は「日」は0となるかそもそも追加されていません。 （例：2004,4,0　2004,4） 現在の実装では常に月一括取得なので日の値は見る必要はありませんが、将来の拡張に備えて対応しても良いでしょう。 レスポンス Valueヘッダでその日付のスケジュールデータ取得用URLを返します。 ID: getschedule リクエスト Reference0：ダウンロード済のファイルの位置 geturlリクエストで返したURLからのデータ取得が完了すると、 本体は一時ファイルにデータを保存しgetscheduleをリクエストします。 レスポンス 次のような形式でデータを返してください。 Reference?: type[TAB]year[TAB]month[TAB]day[TAB]starthour[TAB]startminute[TAB]endhour[TAB]endminute[TAB]caption[TAB]subtitle[TAB]script [TAB]はタブ文字です。1つのスケジュールごとに1つのReferenceヘッダを追加していきます。Valueヘッダはありません。 それぞれの要素の説明については、SCHEDULE/1.0仕様に準じます。 ID - geturlpost リクエスト Reference0：上記スケジュール形式 レスポンス Value：GET/POST Reference0：送信先URL ( http://ssp.shillest.net/hogehogehoge.cgi ）のようにパラメータ以外 Reference1：エンコードされていないパラメータ Reference2：呼び出し用文字コード スケジュール送信機能で利用されるリクエストです。 Valueでデータ送信用メソッド、Reference0でパラメータを除いた送信先URL、Reference1でPOSTもしくはGETで送られるデータをURLエンコードされていない形式で返します。 Reference2はReference1のデータを実際にHTTPでするときに利用される文字コードです。省略するとレスポンスのCharsetを利用します。 ■レスポンスの例 レスポンスの例は以下のとおりです。 CRLF区切りはリクエストと同様ですので[CRLF]は省略しています。 SCHEDULE/2.0 200 OK Charset: Shift_JIS Value: POST Reference0: http://ssp.shillest.net/hogehogehoge.cgi Reference1: schedule=すけじゅうる&year=2004&month=4&date=2 Reference2: EUC-JP ■スケジュールセンサID スケジュールセンサごとに一意につけられるIDです。 ぶつかる可能性が「極端に低い」63バイトまでの1バイト文字列なら何でもかまいません。 通常、GUID/UUIDと呼ばれるものを使います。 ※それなりに開発環境をそろえておられる方なら、guidgen.exeのRegistry Formatが生成に使えると思います。 ※ない人はこちら　＞　http://ssp.shillest.net/docs/guid.zip ※処理系側は最低でも63バイトまで受け付ける必要がありますが、そもそも制限を設けないことを推奨します。 descript.txtのIDエントリに、次のように書いてください。 例：id,3491996A-B383-4890-B863-5CE258678093 意味的には、このIDが同じであるということは、たとえ名前が変っても互換性がある、という事を示すことになります。 --------------------------------------- by:SSP BUGTRAQ 開発部 ・内容の正確性については保証しません。バグってるかも。 ・この文書は営利目的でない限り自由に配布・複製・変更（変更したものの再配布含む）することができます。 ・予告無く変更されることがいっぱいありますが、刺さないでね。 ・というか煮るなり焼くなり好きにしてくださいまし。