Prologサーバー
SWI-PrologのPrologサーバのトップ
サーバ(_ポート) :-
tcpソケットの準備(_ソケット,_ポート),
接続されたらソケットを開く(_ソケット, AcceptFd, _),
tcpインタプリタ(AcceptFd).
tcpソケットの準備(_ソケット,_ポート) :-
tcp_socket(_ソケット),
tcp_bind(_ソケット, _ポート),
tcp_listen(_ソケット, 5).
接続されたらソケットを開く(AcceptFd,_ソケット,_Peer,In,Out) :-
tcp_accept(AcceptFd, _ソケット, _Peer),
tcp_open_socket(_ソケット, In, Out).
tcpインタプリタ(AcceptFd) :-
repeat,
行を読みだして実行(AcceptFd),
fail. >>178 冒頭に以下の行が入るのだった。
:- use_module(library(socket)).
サーバ(_ポート) :-
・・・ % 以下つづく。本当は親タスクにassertできたりするがここでは省略。
tcpインタプリタ(AcceptFd) :-
repeat,
行を読みだして実行(AcceptFd),
fail.
行を読みだして実行(AcceptFd) :-
接続されたらソケットを開く(AcceptFd,_ソケット,_Peer,In,Out),
一行読み出し項に変換(In,_項),
インタプリタの実行(_ソケット,In,Out,_項).
インタプリタの実行(_ソケット,In,Out,_項) :-
thread_create(項を実行して結果を返す(In, Out, _項),_,[]).
項を実行して結果を返す(In, Out, _項) :-
( catch(_項,_エラー情報,エラー情報の送信(Out,_エラー情報));
_項=false),!,
情報を送信する(Out,_項),
ストリームを閉じる(In,Out). 一行読み出し項に変換(In,_項,_エラー情報) :-
行入力(In,_行),
行を解析して項を得る(_行,_項,_エラー情報).
行を解析して項を得る(_行,_項,_エラー情報) :-
catch(read_term_from_atom(_行,_項,[]),_エラー情報,_項 = false).
行入力(In,_行) :-
read_line_to_codes(In,Codes),
atom_codes(_行,Codes).
エラー情報の送信(Out,_エラー情報) :-
format('~w\n',[_エラー情報]),
format(Out,'~w\n',[_エラー情報]).
情報を送信する(Out,_項) :-
項を文字列に変換する(_項,_文字列),
書き出す(Out,_文字列).
書き出す(Out,_文字列) :-
format(Out,'~w\n',[_文字列]),
flush_output(Out).
項を文字列に変換する(_項,_文字列) :-
swritef(String,'%t',[_項]),
string_to_atom(String,_文字列).
ストリームを閉じる(In,Out) :-
close(In),
close(Out).
送信項と受信項の単一化(_項,_項).
エラー発生時はfail扱い :-
fail. >>178
ここの十数行がやはり大事で、ここさえ押さえれば、サーバプログラムは大丈夫。
同じく省略しているが 行を読みだして実行/1 の冒頭で GET/POST行の解析等が
来るから、ここからの分岐は実際はもう少し重くなる。Prolog項が取れてからは
単純だが、副作用として出力をどのように処理するか、クライアントとどこまで
協調するかなど、実際の設計は難しい。 「副作用としての出力をどのように処理するか」
だな。 クライアントから述語呼び出しを findall(_述語,_述語,L) に一皮被せて
対話(findall(_述語,_述語,L),Q) とするという方法もある。
サーバーはLに述語の解リストを返すが、それと共にQにクライアントが
次に取るべき行動を指示する。例えば
Q に see_other('http://xxx.org/tmp/fileaaa.html') が入ってきたりする。
このQをクライアントが受け取り、call(Q) することでサーバーが用意した
htmlファイルをクライアント側のブラウザに表示できる。 これでクライアントがProlog処理系である場合はうまく行く。それでは、
クライアントがChromeのようなブラウザであり、actionでサーバアドレスや
ポートを指定し、inputやselectタグで述語引数情報を送ってくる場合は
どうか。
対話の相手がブラウザてあると、対話/2もfindall/3も理解してくれない。
この場合はhtmlファイルを直接、Socketのストリームに出力する必要が
あるだろう。もしそうだとしたら、それではクライアントがProlog処理系
であるか、ブラウザであるかはどの見分ければよいのだうか。 最後の行を訂正する。「ブラウザであるかをどのように見分ければ良いのだろうか」
有力な方法としてinputとタグとしてname=定義域 value= に固有のブラウザ名~
入れておくという方法がある。サーバは定義域としてget/post情報の中の
定義域キーの情報を調べて、この中に登録済みのブラウザ名を値として発見
した場合はクライアントはブラウザとして振る舞う。これが一番簡単な解決法
であろう。 この話よくわからないのですが、
Prologクライアントからの質問には、質問の項を解決したものを返す。
ブラウザからの質問には、たとえば Moved Temporarily ステータスで
再度参照するべきファイル名を返す。というようなことですか。 >>187
基本的にはそういう話です。
ブラウザへの応答は必ずしも別ファイルに書いてから
Moved Temporarily や See Other を返すのではなく、直接
ストリーム出力するのでもよいと思います。
ここ暫くは、最も悪影響が少なくブラウザであるか、
Prologクライアントであるかを判断させるサインの出し方の
話でした。 ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 目下、Prologサーバーの大幅書き換え中。
EUCだったIF/Prolog版からMTF8のSWI-Prolog版への書き換え。 >>177 -debug ではなくて
# w3m -dump http:// ・・・
ですね。 >>191
SWI-Prologだと
?- www_open_url('http://・・・').
でも行くことができます。ただこの場合、多分デスクトップにWEBブラウザが表示されてしまいますね。'. Google ChromeからSWI-Prologで書かれたサーバーから情報取得後、
表示されたHTMLファイルを<<更新>>しないとサーバー側の接続が切れないと
いう現象が発生しているのだが、何がいけないのだろうか。Firefoxでは起こらない。 >>193
20年も昔には、こういうトラベルが発生するとプロキシサーバーを介してやってみたりした。そうするとなぜかうまくいったり。 
