|
Thanks for responding so completely.
1. I think separating the Qt GUI out using MVC would be a great fit here. If there was a controller layer between the database and the gui, including a task manager, then both the Qt Gui and the Web server could run as equal citizens, accessing the controller framework. It wouldn't matter if either or both were running. As tasks were added from each, they would be put into the same scheduler. This could be as simple as rewriting the job manager, and having any editing tasks from the gui be added as jobs. Both the gui and CS would need to be informed of database changes, and refresh. As far as the locking goes, can you assume that SQLite will lock successfully if both processes are on the same system?
2+3. Agreed, sounds good. It would be nice to be able to have plugins to add ajax hooks and functionality to the server, and javascript to access those hooks. Perhaps have known lists like header buttons, per book options, etc, and let the plugins add html snippets to those lists when they add in their ajax hook.
4. There are a number of javascript epub viewer libraries, so this seems pretty easy to integrate. If plugins could be added to the CS, then wrapping one or more of the ebook viewers up as a plugin would make it easy to add, update, and replace.
5. I think this could be a place where you could use one of the light-weight CMS frameworks. You'd get the user management, plus quite a lot of other features but its overkill and none of the user config would be available to the Qt Gui. If you don't want to do that, it might be better to just let users configure a proxy server to provide authentication to the CS.
6. This would be a great feature, but could be solved by running multiple CS. The user would just have to configure each to use different ports and run different libraries.
Note. Unfortunately, that's why I was looking to use the job manager to consolidate any write requests into one thread.
|