[Ldsoss] Wireless Networks in Church Buildings

Fri Nov 24 09:47:57 EST 2006

Hi Steve,

I haven't commented in specific terms about how difficult changes in  
this area would be to MLS; I made a few general statements about the  
additional complexity that concurrency adds to applications, and I  
did that to indicate perhaps why the MLS team hasn't made those  
changes yet.

The problem at hand is making clerks wait for data transmission and  
MLS updates. As we can see by the numerous comments so far, there are  
a near-infinite set of ways to fix that problem; many solutions don't  
involve added concurrency to MLS itself or any other significant re- 
engineering, such as the idea to do the updates as part of a separate  
process scheduled to run at some late/early hour of the day. (While  
Windows doesn't have cron, W2K and later have a fairly useful  
scheduling engine, but regardless, writing a daemon program that does  
its own scheduling is not difficult.)

And please, keep the feedback coming in terms of how MLS doesn't work  
well for you, and how you wish it worked. The MLS team is constantly  
listening to these issues and addressing them as best they can.

Best,

Ben

On Nov 23, 2006, at 8:49 AM, Steven H. McCown wrote:

> I think you're making the problem harder than it needs to be.  Just  
> take a
> snapshot (of transactions) when the program ends (or when the cmd is
> entered) and send it in the background.  You only need to lock the  
> database
> while the snapshot is being created.  Then, you just make sure that  
> you keep
> the snapshots in order.  Once the snapshot is created, you can keep  
> using
> the system -- even before transmission.  This is an issue of  
> simultaneous
> action, but not one of concurrency with inter-process  
> synchronization.  IOW,
> it's not a full-blown transaction server with many simultaneously  
> updating
> parties.
>
> Steve
>
> -----Original Message-----
> From: ldsoss-bounces at lists.ldsoss.org
> [mailto:ldsoss-bounces at lists.ldsoss.org] On Behalf Of Ben Galbraith
> Sent: Wednesday, November 22, 2006 4:10 PM
> To: LDS Open Source Software
> Subject: Re: [Ldsoss] Wireless Networks in Church Buildings
>
> 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
>>
>
> _______________________________________________
> 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
>