Difference between revisions of "Apertium-apy"

From Apertium
Jump to navigation Jump to search
Line 4: Line 4:
 
Currently the server accepts a translation request, sends it through the translate() function (which is currently pointing to translateMode() and bypassing the other possible translate*() functions). The problem is that if multiple requests are received too quickly (which happens often even with a single user, since the web interface we're using updates ~live while the user is typing), the server is still processing a previous request and gets "stuck". I.e., it'll continue accepting requests, but cannot return them.
 
Currently the server accepts a translation request, sends it through the translate() function (which is currently pointing to translateMode() and bypassing the other possible translate*() functions). The problem is that if multiple requests are received too quickly (which happens often even with a single user, since the web interface we're using updates ~live while the user is typing), the server is still processing a previous request and gets "stuck". I.e., it'll continue accepting requests, but cannot return them.
   
So the behaviour we would like is that the server accept requests, and queue them until each translation is ready to send back. It should send translations back in the order in which they were received. It should also be possible to set a time-out for translation threads, so if a translation is taking too long, it gets killed and the queue moves along.
+
So the behaviour we would like is that the server accept requests, and queue them until each translation is ready to send back. It should send translations back in the order in which they were received. It should also be possible to set a time-out for translation threads, so if a translation is taking too long, it gets killed and the queue moves along. So we probably need something like the Queuing example here at tutorialspoint dot com /python/python_multithreading.htm . Assistance welcome.

Revision as of 23:01, 14 September 2013

Apertium-APy stands for "Apertium API in Python". It's a simple apertium API server written in python, meant as a drop-in replacement for ScaleMT. It is currently found in the svn under trunk/apertium-tools/apertium-apy, where servlet.py is basically its entirety. This is meant for front ends like the simple one in trunk/apertium-tools/simple-html (where index.html is the main deal).

Threading

Currently the server accepts a translation request, sends it through the translate() function (which is currently pointing to translateMode() and bypassing the other possible translate*() functions). The problem is that if multiple requests are received too quickly (which happens often even with a single user, since the web interface we're using updates ~live while the user is typing), the server is still processing a previous request and gets "stuck". I.e., it'll continue accepting requests, but cannot return them.

So the behaviour we would like is that the server accept requests, and queue them until each translation is ready to send back. It should send translations back in the order in which they were received. It should also be possible to set a time-out for translation threads, so if a translation is taking too long, it gets killed and the queue moves along. So we probably need something like the Queuing example here at tutorialspoint dot com /python/python_multithreading.htm . Assistance welcome.