|
The communication only needs to be one way, i.e. CS->GUI not the other way around. The CS does not maintain live views of data, unlike the GUI, therefore the db layer takes care of GUI->CS updating automatically.
Jobs are asynchronous, making every single write operation asynchronous is never going to fly. The performance and usablity would absolutely suck. Imagine having to launch a job every time you edit a single title in the book list.
CMS frameworks wont work, they will use bog standard HTTP form based authentication, which will not work for us, since we can't use ssl. Also, the CS offers a much more dynamic view of the underlying database than the typical CMS framework even dreams of.
In any case auth issues are mostly orthogonal to the rest. They can be addressed after the basic refactoring is done, as long as the refactoring keeps session management in mind, the exact details of the implementation can be switched around later.
For the viewer, I will simply use the same code I developed for the calibre viewer, which is tested, works, is well designed and most importantly maintainable by me, since I am the one that has to deal with the "my book isn't looking right in your viewer" bug reports.
|