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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
