MobileRead Forums - View Single Post

blackjag · 08-09-2013, 02:44 PM

I disagree about making jobs asynchronous bringing down performance. A proper job executor would allow for way more performance optimization while abstracting the implementation from the plugin developers. Need device jobs to execute synchronously? Then have a separate single thread executor for each device that's added. As jobs for a specific device id are added simply throw them on the end of the queue for that device. This sort of executor allows you to decide what needs to be synchronous and what doesn't, and best of all gets every write operation off the gui event dispatch thread.
To use your example of editing a book's title, perhaps the edit could happen on the database cache and release the event dispatch thread to allow the user to continue using the program. Then, asynchronously, edits to the book itself and the write out of the database change could be added to the executor. The edit is instantaneous as far as the user is concerned, and the i/o can happen as fast as it can without blocking the user. Since the database view has already been updated, the user can proceed just like the entire operation has already completed. This might involve using a task class for i/o that's lighter weight than the current job class.
That setup makes the most sense to me, but I can also see how you would be more comfortable just adding in hooks to have the CS inform the GUI of each change and not change up the existing code too much. I'm not trying to get you to rewrite the entire codebase, just trying to get a feel for some of your architectural decisions and future plans. I'd love to help and if any of these ideas sound good to you, I can upload some UML or a code prototype to better communicate what I'm talking about.
In any case, all write operations from the CS should be asynchronous. Also, I would argue that the CS needs a live data cache as much as the GUI, since it needs to support a fair number of users simultaneously browsing and downloading.
Also, I'm not sure what you mean about the CS being far more dynamic than a CMS. Are you just talking about the ease of adding and removing metadata and columns? In any case, I agree that a CMS isn't a very good fit, but if you really want to set up multiple users, with permissions on a per book or per library basis it seems silly to try to write that from scratch instead of just using the parts of an existing system that might fit.

08-09-2013, 02:44 PM	#5
blackjag Junior Member Posts: 4 Karma: 10 Join Date: Aug 2013 Device: Amazon Kindle	I disagree about making jobs asynchronous bringing down performance. A proper job executor would allow for way more performance optimization while abstracting the implementation from the plugin developers. Need device jobs to execute synchronously? Then have a separate single thread executor for each device that's added. As jobs for a specific device id are added simply throw them on the end of the queue for that device. This sort of executor allows you to decide what needs to be synchronous and what doesn't, and best of all gets every write operation off the gui event dispatch thread. To use your example of editing a book's title, perhaps the edit could happen on the database cache and release the event dispatch thread to allow the user to continue using the program. Then, asynchronously, edits to the book itself and the write out of the database change could be added to the executor. The edit is instantaneous as far as the user is concerned, and the i/o can happen as fast as it can without blocking the user. Since the database view has already been updated, the user can proceed just like the entire operation has already completed. This might involve using a task class for i/o that's lighter weight than the current job class. That setup makes the most sense to me, but I can also see how you would be more comfortable just adding in hooks to have the CS inform the GUI of each change and not change up the existing code too much. I'm not trying to get you to rewrite the entire codebase, just trying to get a feel for some of your architectural decisions and future plans. I'd love to help and if any of these ideas sound good to you, I can upload some UML or a code prototype to better communicate what I'm talking about. In any case, all write operations from the CS should be asynchronous. Also, I would argue that the CS needs a live data cache as much as the GUI, since it needs to support a fair number of users simultaneously browsing and downloading. Also, I'm not sure what you mean about the CS being far more dynamic than a CMS. Are you just talking about the ease of adding and removing metadata and columns? In any case, I agree that a CMS isn't a very good fit, but if you really want to set up multiple users, with permissions on a per book or per library basis it seems silly to try to write that from scratch instead of just using the parts of an existing system that might fit.