OK, while I'm making suggestions ...
I guess this one might be quite a bit more work (so I could understand you wanting sponsorship for something like this), but I think it might be a good idea for those cold, dark winter days ...
My suggestion is to make a library version of FET, rather like the command-line version, but interfacing via some communication mechanism (callbacks, messaging, whatever, ...). Or it could be an HTML server, using JSON messages for example ...
Anyway, this FET version would create no files, but pass all generated data and progress information back to the client, which could do with it whatever it wanted. Control of the processes, setting of options, etc., would be done by messages from the client.
Dear Michael,
Indeed, lack of financial support is the big problem. Also, I don't have much knowledge with these (I don't even know what "callbacks" mean), but I would be willing to learn and collaborate.
But I will add your words in the TODO list.
I guess the "best" variant for this is using a REST api. But I fear both (your and also my idea) will be very difficult, since you don't need to write only the api, you also need to care that fet will run all request on the same time. So internally it must be able to generate 2 and more different timetables at the same time. I fear timetabling is much too difficult for this, since it is not a "static" database. The generating part is highly dynamic and all guys want to start and stop their own generating at the same time.
Volker, you are of course right about the difficulties of a proper REST API. If that part of FET is not already thread-safe, it could be quite a lot of work. I can see from the Multiple-Generate feature that FET has some multithreading features already, but the threads are all using the same input file, which is perhaps less demanding.
It might be easier to take fet-cl as a basis and change the IO parts so that they don't write to files but send their output to stdout (or a socket). There could be a sort of query API using stdin (or a socket), so that only the desired outputs are returned. Then a lot of the command-line options would be unnecessary. A separate instance of this new version could be started (by the controlling software) for each input file. Progress could be monitored by sending polling queries.
Something like this can be done already using fet-cl (it is what I do in fetrunner), but the communication is via command line options and the output files, which are otherwise unnecessary and get deleted soon afterwards anyway. These are also more difficult to interface to (like repeatedly reading and parsing the logs/max_placed_activities.txt file to get the progress).
Yes, the threads use all the same input file. That saves a lot of memory, since translating the "human constraints" into optimized "algorithm constraints" is only needed one time. Doing that for each thread will be some work and waste a lot of memory (and a bit time) for "normal" users. My copy so many times the same data, it might not fit into the cache memory anymore and generating will slow down very much.
Yes, only doing that with only a single file should be much easier. But then the other application and fet-cl need to be configured for several fet-cl files. Not sure if that is a good/easy approach.