On 11/22/06, Ben Galbraith <[EMAIL PROTECTED]> wrote:
...
Having said that, as has already been observed in this list, Afaria
does the communication for MLS. Thus, there is already a separate process performing the communication. Discussions about creating separate threads to do this or that at the data transmission layer is orthogonal to the issue at hand. The issue is whether MLS deals with the complexities of allowing you to use the program while the data transfers in the background. Among the issues to consider are: how to notify the user of the status of the transfer in progress, how to reconcile live changes you may be making with conflicting changes that may be received from the server, what to do if you try to quit the application while the transfer is in process, how to prevent re-entry to the same process, and so forth. Compare this complexity with "display modal dialog to user". These problems, when viewed individually, are not rocket science. In aggregate, the additional complexity in simply designing the user experience for a multi-tasking interface is considerable, and that's not including all the complexities associated with the implementation of the interface and ensuring that race conditions and deadlocks are all properly handled (conditions which are difficult at best to debug). I'm not saying one shouldn't design multi-tasking GUIs and so forth. But please understand it's not an issue of saying, "Oh, let's flip the thread switch and the problem is solved." It's an undertaking, one that must be prioritized with a long list of additional undertakings. But as I said originally, I'll pass the feedback along. I can't speak for the MLS team or the Church in any official capacity, but I am aware of many discussions by those responsible for MLS on this topic and I anticipate a solution to these problems will emerge.
I wonder how feasible it would be to simply schedule the transmission once per day at a time when the system is not likely to be used. (1am?) After all, is there any reason why the transmission has to be user initiated? (It's fine that it is, but does it require it?) I would imagine that it would be a simple task to 'cron' due to the fact that the communication layer is already abstracted from MLS as it is. Of course this would also relieve the poor finance clerk who has been there for 1.5+ hours after the block because he had to wait for all the settings apart, all the temple recommend interviews, and finally all the money counting to conclude, only to print out 2 reams of membership updates that came in with his finance transmission report. Naturally, I'm exaggerating, but I can't think of any reason why the transmission couldn't be once per day at a non-used time, with additional transmissions to be initiated by the user if desired. Even better, SLC could more accurately anticipate the incoming transmission load, because each unit would only need to transmit once/day instead of multiple times. Then in the morning, when you fire up MLS, you could retrieve the printouts you wanted, and file them away. This would also allow the finance clerk to select only the finance reports, and the membership reports for the membership clerk, and so on. Wow, I'm starting to like this idea. Running with that idea, we could just simply put all the reports into a menu item, like file->reports or something with subcategories like file->reports->finance, and file->reports->membership. Then we won't be required to print them right away after transmitting, which means the finance clerk wont be forced to print or lose the membership updates. Bah, now I'm rambling... At any rate, for the concurrency issue, I simply suggest that MLS create a snapshot of the database, and put in a Read-Only mode so that when Afaria kicks off to transmit, MLS can still be used for reporting purposes. Fairly simple to implement since there is not conflict resolutions to overcome and a good middle ground for users because they can still view MLS data. To avoid the whole locked MLS being an inconvenience to users, I like the cron idea. Of course, YMMV. -- Joe
_______________________________________________ Ldsoss mailing list [email protected] http://lists.ldsoss.org/mailman/listinfo/ldsoss
