Hi Ben, My comments below...
Ben Galbraith wrote: > 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. Agree... > > Dealing with the complexity of having created the thread == hard. > It can be in some situations. Generally not, when design is proper. > 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." Ok, I won't argue that, given these folks are talking Java, etc. However, I will disagree with the threading model comment. It doesn't take a PhD to improve a threading model as evidenced by such examples as BSD, Linux, and the like. As to dealing with concurrency, that was the same problem facing programmers back in the 50's and 60's, so this is nothing new. Back in my generation, the scaling complaint with concurrency was with COBOL, RPG, etc. Wrong tool for the job, but people tried anyway. Java was originally designed for the General Instruments set top box. It has since grown into the amalgamation it is today. I'm not saying Java is not useful, but I do not like the design of the language and extensions for concurrency, as that was never part of the core, when Gosling first wrote it. My tools of choice include C, which by it's simplicity of design (created to write operating systems, etc.) allows for concurrency, object modeling, and all the goodies many of the current and coming generation of programmers think is the foundation of computing. It's not, but then most of the new EE's in the last 10 years don't design with discrete components, but rather IC's and ASIC's. It's all a matter of perspective. The advantage of many of these tools you have to work with is that you can abstract the hardware and many times the OS away from the application development. This is also the short coming. Without a clear understanding of how an OS works, how a scheduler threads, how many of the "hidden" functions work, you are left totally dependent on the abstracted layer to get the job done. This only comes back to bite you when things do not work as they should. Personally, I think Unix and it's variants work just fine for concurrency, especially when you have tools like X, Qt and an OS that is designed from the ground up to be multi-user, multi-tasking. It makes the job that much easier, since you don't have to fight the environment. But I digress. > > 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". Common issues in a MU/MT environment. > > 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 sorry Ben, I just don't share your sense of the complex here. > > 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 people are going to get all wound up about this as being difficult, please, don't bother. It will only cause more confusion. > If only this were simply an issue of a communications layer. That, as > you are right to say, is the easy part. > > Best, > > Ben > I can appreciate your position. But as I said before, this is all a matter of perspective. My days of programming and design were centered around solving problems like this all the time, and with much more "primitive" tools and kernels. I did not learn to program in a modal environment such as DOS/Windows. Do they not teach these basic skills anymore? The root problem, as you have partly surmised, is not in the technique of threading, etc. but manifests in the design of the application. However, it's not application, but the mindset around it's creation that needs to change before real progress is going to be made. If you have a group of software people that understand monolithic / modal only - that is what you will get for a solution every time. It's what they know. That's not a bad thing, but it's not a one size fits all solution. Best, ...Paul > > >> >> 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@lists.ldsoss.org >>>> http://lists.ldsoss.org/mailman/listinfo/ldsoss >>>> >>>> >>>> >>> _______________________________________________ >>> Ldsoss mailing list >>> Ldsoss@lists.ldsoss.org >>> http://lists.ldsoss.org/mailman/listinfo/ldsoss >>> >>> >> >> _______________________________________________ >> Ldsoss mailing list >> Ldsoss@lists.ldsoss.org >> http://lists.ldsoss.org/mailman/listinfo/ldsoss >> > > _______________________________________________ > Ldsoss mailing list > Ldsoss@lists.ldsoss.org > http://lists.ldsoss.org/mailman/listinfo/ldsoss > > > --No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.430 / Virus Database: 268.14.14/547 - Release Date: > 11/22/2006 5:41 PM > > _______________________________________________ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
