Difference between revisions of "Apertium-apy"
Firespeaker (talk | contribs) (Created page with ''''Apertium-APy''' stands for "'''Apertium''' '''A'''PI in '''Py'''thon". It's a simple apertium API server written in python, meant as a drop-in replacement for ScaleMT. I…') |
Firespeaker (talk | contribs) |
||
| 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. It should send translations back in the order in which they were received. |
So the behaviour we would like is that the server accept requests, and queue them until each translation is ready to send. 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. |
||
Revision as of 20:57, 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. 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.
