[Ldsoss] Wireless Networks in Church Buildings

[Idaho Joe]

On 11/22/06, Ben Galbraith <junk at galbraiths.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ldsoss.org/pipermail/ldsoss/attachments/20061122/e3ce0416/attachment.html