Returning JSON output from a handler thread still running?

[Torbjörn Lager-2]

Hello,

Please have a look at the following code:

:- use_module(library('http/thread_httpd')).
:- use_module(library('http/http_dispatch')).
:- use_module(library('http/json')).
:- use_module(library('http/http_json')).

:- http_handler('/doit', doit, [spawn([alias(test)])]).

doit(_Requestl) :-
    reply_json(json([a=result])),
    thread_get_message(Event),
    process(Event).

:- http_server(http_dispatch, [port(5000)]).


The call to thread_get_message/1 blocks (as it should), which seems to
imply that no JSON is returned to the browser (until I kill the
server). Does it have to be that way (I don't see why)? Is there any
way I can send JSON to the client and still keep the thread on the
server running?

(What I'm trying to find here is a way to ask for one solution at the
time for a Prolog goal entered in a web interface. I have written code
that should have worked, had only the above worked... Maybe there are
other ideas for how to accomplish what I want to do? I've looked at
Uwe Lestas N-Queens demo, but it striked me as too complicated, and I
really would like to work against the SWI webserver...)

Thanks in advance!

Best regards,
Torbjörn

--
Torbjörn Lager
Professor of General and Computational Linguistics
Department of Philosophy, Linguistics and Theory of Science
Box 200, SE-405 30 Göteborg, Sweden
Phone: [phone]
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Jan Wielemaker-3]

On Thursday 18 June 2009 14:57:27 Torbjörn Lager wrote:

> Hello,
>
> Please have a look at the following code:
> :- use_module(library('http/thread_httpd')).
> :- use_module(library('http/http_dispatch')).
> :- use_module(library('http/json')).
> :- use_module(library('http/http_json')).
> :
> :- http_handler('/doit', doit, [spawn([alias(test)])]).
>
> doit(_Requestl) :-
>     reply_json(json([a=result])),
>     thread_get_message(Event),
>     process(Event).
>
> :- http_server(http_dispatch, [port(5000)]).
>
> The call to thread_get_message/1 blocks (as it should), which seems to
> imply that no JSON is returned to the browser (until I kill the
> server). Does it have to be that way (I don't see why)? Is there any
> way I can send JSON to the client and still keep the thread on the
> server running?

Not easily. The whole infrastructure is designed to deal with finishing
the reply on completion of the handler. What you can do is enable
session management (you need that anyway) and create a thread that is
associated to the session. That is where you have the state-full
computation and you send messages back and forth between the HTTP
handlers and the session thread to communicate queries and results.

Would be nice to have a demo using this scenario in the HTTP server
examples directory ...

More in general, I'm looking for good examples for this (and other)
packages.  If you have things to share or are willing to write examples,
please share them.

        Cheers --- Jan

> (What I'm trying to find here is a way to ask for one solution at the
> time for a Prolog goal entered in a web interface. I have written code
> that should have worked, had only the above worked... Maybe there are
> other ideas for how to accomplish what I want to do? I've looked at
> Uwe Lestas N-Queens demo, but it striked me as too complicated, and I
> really would like to work against the SWI webserver...)
>
> Thanks in advance!
>
> Best regards,
> Torbjörn

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Torbjörn Lager-2]

Jan, thanks for your comments. I think the scenario is important
enough to warrant work in the area, so, guided by your advice, I may
give it a try (a couple of code snippets detailing some aspects of
your proposed solution would be helpful though!).

> More in general, I'm looking for good examples for this (and other)
> packages.  If you have things to share or are willing to write examples,
> please share them.

I recognise the need for good examples, so to the best of my
abilities, and with some guidance, I'm willing to contribute. See my
next message!

Best,
Torbjörn

On Fri, Jun 19, 2009 at 9:40 AM, Jan Wielemaker<J.Wielemaker@...> wrote:

> On Thursday 18 June 2009 14:57:27 Torbjörn Lager wrote:
>> Hello,
>>
>> Please have a look at the following code:
>> :- use_module(library('http/thread_httpd')).
>> :- use_module(library('http/http_dispatch')).
>> :- use_module(library('http/json')).
>> :- use_module(library('http/http_json')).
>> :
>> :- http_handler('/doit', doit, [spawn([alias(test)])]).
>>
>> doit(_Requestl) :-
>>     reply_json(json([a=result])),
>>     thread_get_message(Event),
>>     process(Event).
>>
>> :- http_server(http_dispatch, [port(5000)]).
>>
>> The call to thread_get_message/1 blocks (as it should), which seems to
>> imply that no JSON is returned to the browser (until I kill the
>> server). Does it have to be that way (I don't see why)? Is there any
>> way I can send JSON to the client and still keep the thread on the
>> server running?
>
> Not easily. The whole infrastructure is designed to deal with finishing
> the reply on completion of the handler. What you can do is enable
> session management (you need that anyway) and create a thread that is
> associated to the session. That is where you have the state-full
> computation and you send messages back and forth between the HTTP
> handlers and the session thread to communicate queries and results.
>
> Would be nice to have a demo using this scenario in the HTTP server
> examples directory ...
>
> More in general, I'm looking for good examples for this (and other)
> packages.  If you have things to share or are willing to write examples,
> please share them.
>
>        Cheers --- Jan
>
>> (What I'm trying to find here is a way to ask for one solution at the
>> time for a Prolog goal entered in a web interface. I have written code
>> that should have worked, had only the above worked... Maybe there are
>> other ideas for how to accomplish what I want to do? I've looked at
>> Uwe Lestas N-Queens demo, but it striked me as too complicated, and I
>> really would like to work against the SWI webserver...)
>>
>> Thanks in advance!
>>
>> Best regards,
>> Torbjörn
>
>
>
>

--
Torbjörn Lager
Professor of General and Computational Linguistics
Department of Philosophy, Linguistics and Theory of Science
Box 200, SE-405 30 Göteborg, Sweden
Phone: [phone]
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Torbjörn Lager-2]

Jan,

Ok, I've followed your advice to the best of my abilities and I have a
demo that sort of works. The problem is that it only works MOST of the
time, so there seems to be som kind of synchronization issues that I
don't really understand.

I have attached code (server in Prolog and client in HTML +
Javascript). The code is very simple (I guess that's why it doesn't
work ALL the time.) You run it by simply loading the Prolog file and
then direct your browser to <http://localhost:5000/solver>. (Warning:
This exposes your Prolog process to the world!). You may want to run
the demo in Firefox, using Firebug to monitor the HTTP traffic.

Problems that I see are:
- Clicking Next (to get the next solution to a goal) sometimes doesn't
come back at all. The HTTP request just hangs there, forever. I do not
understand why.
- There is also a problem with using the session ID as the name of the
thread that runs the actual Prolog goal. Sometimes the name is already
taken. I understand why this is happening (the thread is still
running), but I don't know what to do about it (aborting the running
thread by force?)

I do intend to make this into a nice demo for the examples directory,
but that would make sense only if it works. So I'm hoping for some
kind of clue!

Best regards,
Torbjörn


On Fri, Jun 19, 2009 at 9:40 AM, Jan Wielemaker<J.Wielemaker@...> wrote:

> On Thursday 18 June 2009 14:57:27 Torbjörn Lager wrote:
>> Hello,
>>
>> Please have a look at the following code:
>> :- use_module(library('http/thread_httpd')).
>> :- use_module(library('http/http_dispatch')).
>> :- use_module(library('http/json')).
>> :- use_module(library('http/http_json')).
>> :
>> :- http_handler('/doit', doit, [spawn([alias(test)])]).
>>
>> doit(_Requestl) :-
>>     reply_json(json([a=result])),
>>     thread_get_message(Event),
>>     process(Event).
>>
>> :- http_server(http_dispatch, [port(5000)]).
>>
>> The call to thread_get_message/1 blocks (as it should), which seems to
>> imply that no JSON is returned to the browser (until I kill the
>> server). Does it have to be that way (I don't see why)? Is there any
>> way I can send JSON to the client and still keep the thread on the
>> server running?
>
> Not easily. The whole infrastructure is designed to deal with finishing
> the reply on completion of the handler. What you can do is enable
> session management (you need that anyway) and create a thread that is
> associated to the session. That is where you have the state-full
> computation and you send messages back and forth between the HTTP
> handlers and the session thread to communicate queries and results.
>
> Would be nice to have a demo using this scenario in the HTTP server
> examples directory ...
>
> More in general, I'm looking for good examples for this (and other)
> packages.  If you have things to share or are willing to write examples,
> please share them.
>
>        Cheers --- Jan
>
>> (What I'm trying to find here is a way to ask for one solution at the
>> time for a Prolog goal entered in a web interface. I have written code
>> that should have worked, had only the above worked... Maybe there are
>> other ideas for how to accomplish what I want to do? I've looked at
>> Uwe Lestas N-Queens demo, but it striked me as too complicated, and I
>> really would like to work against the SWI webserver...)
>>
>> Thanks in advance!
>>
>> Best regards,
>> Torbjörn
>
>
>
>

--
Torbjörn Lager
Professor of General and Computational Linguistics
Department of Philosophy, Linguistics and Theory of Science
Box 200, SE-405 30 Göteborg, Sweden
Phone: [phone]

[Jan Wielemaker-3]

Hi all,

Torbjörn sent a little program to communicate with Prolog using a
browser.  This problem has some interesting aspects that have been
discussed here several times:

    * Deal with state in Prolog web-servers, where the state is
    maintained on the Prolog stacks (stack, choicepoints, variables).

    * Deal with interactive web-applications (AJAX)

    * Deal with safely calling Prolog code

    * Deal with handling multiple `theories'

Turning this into a nicely working demo can serve several purposes

    * Provide online demos to attract people to your nice library/etc.
    Think of CHR, CLP(FD), etc.  Ulrich: online GUPU?

    * Provide a nice skeleton that can help making Prolog
    more inspiring for students.  It shows cooperation with modern
    web technology and allows them to write something that is nice
    to show to friends.

    * Provide a design pattern and libraries to deal with the four
    issues mentioned above.

Please find below some of the discussion.  I've put the current code
in a new GIT repository on www.swi-prolog.org.  See

        http://www.swi-prolog.org/git/web-prolog.git
or git clone git://www.swi-prolog.org/home/pl/git/web-prolog.git

Who is interested in helping?

        Cheers --- Jan

On Thursday 25 June 2009 05:47:05 pm Torbjörn Lager wrote:

> Jan,
>
> That looks great! I also got myself a valuable lesson, not only for
> how deal with threads in SWI, but also how to debug, etc.  Please go
> ahead and make that announcement on the list. I suppose an N-queens
> demo or something would work, and if no one else steps forward, I'm
> sure I could build one myself.
>
> I was also thinking about creating a small javascript library to accompany
> the code - something that encapsulates the first-next-stop protocol.
> But in order to avoid a dependency on any particular Javscript
> library, maybe it's better to have the server return errors if things
> show up in the wrong order? (I commented out the button selection code
> and I as was the able to break the server...).
>
> What would be the proper way to handle (secure, perhaps also with
> restrictions on size) uploads? To load them into a module created with
> the name of the session?
>
> Shouldn't we rather put safe/1 in a module of its own? Seems somewhat
> orthogoal to the rest of the prolog_server module...
>
> I think spending time on this library is well worth the effort - so
> many interesting apps one could build on top of it!!
>
> BTW, did you check out my chat-demo? Simple, but still something that
> people might want to do.
>
> Thanks!
>
> Best,
> Torbjörn
>
> 2009/6/25 Jan Wielemaker <J.Wielemaker@...>:
> > Torbjörn,
> >
> > I used your file as a source of inspiration. See the modified version
> > attached. There where some issues in your thread handling. Notably,
> > there is little reason to spawn the server threads, but there is reason
> > to manage the solving threads. Also, /prolog/next *can* arrive on a
> > different thread!
> >
> > Would be nice to modularise this a bit further and add support for
> > upoading a program. If we can get all this working we might be able to
> > create a nice tool for the community and a nice demo for handling state
> > through Prolog web-servers.  One of the issues in safe compilation.
> >
> > Now, I just send the files to you privately. Shall we (you? I?) make a
> > query on the list to see if there are people willing to turn this into
> > a nice example and Prolog-demo?
> >
> >        Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Chris Mungall-5]

On Jun 26, 2009, at 1:29 AM, Jan Wielemaker wrote:

> Hi all,
>
> Torbjörn sent a little program to communicate with Prolog using a
> browser.  This problem has some interesting aspects that have been
> discussed here several times:
>
>    * Deal with state in Prolog web-servers, where the state is
>    maintained on the Prolog stacks (stack, choicepoints, variables).
>
>    * Deal with interactive web-applications (AJAX)
>
>    * Deal with safely calling Prolog code

I'd like to see safe/1 separated out into its own library, and made  
hookable, such that I can set up a server and allow access to  
predicates from my modules

(I maintain my own safe-checker module but I'd like to stop doing this)

>
>    * Deal with handling multiple `theories'
>
> Turning this into a nicely working demo can serve several purposes
>
>    * Provide online demos to attract people to your nice library/etc.
>    Think of CHR, CLP(FD), etc.  Ulrich: online GUPU?

Also: to expose a deductive database via prolog queries

>    * Provide a nice skeleton that can help making Prolog
>    more inspiring for students.  It shows cooperation with modern
>    web technology and allows them to write something that is nice
>    to show to friends.

nice!

>    * Provide a design pattern and libraries to deal with the four
>    issues mentioned above.

* A means of allowing other languages to access prolog libraries via  
web services.

* Cloud prolog :-)

> Please find below some of the discussion.  I've put the current code
> in a new GIT repository on www.swi-prolog.org.  See
>
> http://www.swi-prolog.org/git/web-prolog.git
> or git clone git://www.swi-prolog.org/home/pl/git/web-prolog.git
>
> Who is interested in helping?
>
> Cheers --- Jan
>
> On Thursday 25 June 2009 05:47:05 pm Torbjörn Lager wrote:
>> Jan,
>>
>> That looks great! I also got myself a valuable lesson, not only for
>> how deal with threads in SWI, but also how to debug, etc.  Please go
>> ahead and make that announcement on the list. I suppose an N-queens
>> demo or something would work, and if no one else steps forward, I'm
>> sure I could build one myself.
>>
>> I was also thinking about creating a small javascript library to  
>> accompany
>> the code - something that encapsulates the first-next-stop protocol.
>> But in order to avoid a dependency on any particular Javscript
>> library, maybe it's better to have the server return errors if things
>> show up in the wrong order? (I commented out the button selection  
>> code
>> and I as was the able to break the server...).
>>
>> What would be the proper way to handle (secure, perhaps also with
>> restrictions on size) uploads? To load them into a module created  
>> with
>> the name of the session?
>>
>> Shouldn't we rather put safe/1 in a module of its own? Seems somewhat
>> orthogoal to the rest of the prolog_server module...
>>
>> I think spending time on this library is well worth the effort - so
>> many interesting apps one could build on top of it!!
>>
>> BTW, did you check out my chat-demo? Simple, but still something that
>> people might want to do.
>>
>> Thanks!
>>
>> Best,
>> Torbjörn
>>
>> 2009/6/25 Jan Wielemaker <J.Wielemaker@...>:
>>> Torbjörn,
>>>
>>> I used your file as a source of inspiration. See the modified  
>>> version
>>> attached. There where some issues in your thread handling. Notably,
>>> there is little reason to spawn the server threads, but there is  
>>> reason
>>> to manage the solving threads. Also, /prolog/next *can* arrive on a
>>> different thread!
>>>
>>> Would be nice to modularise this a bit further and add support for
>>> upoading a program. If we can get all this working we might be  
>>> able to
>>> create a nice tool for the community and a nice demo for handling  
>>> state
>>> through Prolog web-servers.  One of the issues in safe compilation.
>>>
>>> Now, I just send the files to you privately. Shall we (you? I?)  
>>> make a
>>> query on the list to see if there are people willing to turn this  
>>> into
>>> a nice example and Prolog-demo?
>>>
>>>       Cheers --- Jan
>
> _______________________________________________
> SWI-Prolog mailing list
> SWI-Prolog@...
> https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog