[Ldsoss] Wireless Networks in Church Buildings

[Ben Galbraith]

Hi Paul,

On Nov 22, 2006, at 2:36 PM, Paul Penrod wrote:
> Forking a process for communication does not require significant
> additional complexity
> if it's done right. Even DOS was capable of background transmission,
> which I did way
> back in the 80's. Windows XP is the baseline for all the machines here
> in our stake and
> it is far more capable of background transmission - especially over  
> modem.

Creating a thread == easy.

Dealing with the complexity of having created the thread == hard.

Please allow me to preach to you for a paragraph: It is generally  
acknowledged across all modern programming platforms that the  
problems of dealing with concurrency are amongst the most difficult  
facing software developers today. Anders Hejlsberg (lead architect,  
C#), Doug Lea (foremost Java concurrency expert), Brian Goetz  
(author, Java Concurrency in Practice -- the best concurrency book  
today), and others have all spoken out on this topic. Perhaps Anders  
characterized it best when he told me that today's threading models  
don't scale because "there aren't enough Ph.D.'s in the world."

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.

If only this were simply an issue of a communications layer. That, as  
you are right to say, is the easy part.

Best,

Ben



>
> As someone who spent years in communications - it's not that hard to
> engineer properly
> the first time. These days however, there is a serious lack of talent
> that understands serial
> communications at a low level. They would rather throw it over the  
> fence
> to an API and
> whine about how hard it is, when things don't work.
>
> As a stake financial clerk, I would regularly see 15-30+ minute work
> stoppage due to
> transmission times, cryptic status messages, retransmissions, and
> complete transmission
> restarts, as the modem would lose the connection.
>
> MLS fixing their communications layer (or lack of it) would go a long
> way to make things
> work much better. Also, since it appears you have someone's ear,  
> placing
> useful status
> and/or progress messages in the status window would go a long way in
> help clerks understand
> where they were in the process and in the problem resolution phase  
> where
> they would be on the
> phone with SLC and could articulate where the process died and the
> message that last appeared.
>
> Basic QA...
>
> ....Paul
>>> Also, as finance clerk, I'm pretty good at making sure I transmit my
>>> changes
>>> to SLC.  However, it often annoys me that instead of taking just  
>>> a short
>>> time to transmit my finances, I get a lot of membership updates, and
>>> have to
>>> print out all those reports.  Sometimes I really wish that if a
>>> finance guy
>>> transmits, only the finances are dealt with.  Likewise for  
>>> membership
>>> I'm
>>> sure.  (Although I doubt he ever gets finance reports)
>>
>> Good feedback; I'll pass that along.
>>
>>>  My apologies for the tirade.  It's just something that has always
>>> bothered
>>> me, and I can't explain why.
>>
>> It's a separate thread to explore this topic, but of course we're all
>> very bothered by software that forces us to go through extra work to
>> accomplish repetitive tasks -- especially those of us who by our
>> natures try and be as efficient as possible.
>>
>> Thanks,
>>
>> Ben
>>
>>>
>>> -- 
>>> -- Joe
>>> _______________________________________________
>>> Ldsoss mailing list
>>> Ldsoss at lists.ldsoss.org
>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>>>
>>>
>>>
>> _______________________________________________
>> Ldsoss mailing list
>> Ldsoss at lists.ldsoss.org
>> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>>
>>
>
> _______________________________________________
> Ldsoss mailing list
> Ldsoss at lists.ldsoss.org
> http://lists.ldsoss.org/mailman/listinfo/ldsoss
>