Open source client

[dmoss90660-p40]

From last night's tech talk discussion about family history, it appears that no decision has been made as far as which language to use for the open source client. As I drove home last night, I have some additional thoughts you might want to consider in your decision to either use C++ and widgets, or Java.

1. Cross platform - C++, although "formally" an ISO standard, has significant deviations between compilers, let alone across platforms. Due to the differences just in compilers, it would be more difficult to port code from one platform to another (or one compiler to another). Java does not have this problem.

2. The API - While C++ has a tremendous number of addons, the language itself does not compare to the standard API that comes with Java. This API is available across all platforms Java supports--that's not any additional work the Church has to do--it's done by others. Yet you get the benefit of it.

3. "Grandma doesn't want a 50MB download for the JRE". What does the "typical user" get out of the box on their PC? They get Windows, along with the power of WordPad, Paint and calc. If they want some type of word processor or spreadsheet application, they're going to purchase something on a CD and install it (if they don't have a broadband connection). Or they'll be really patient and download it over their slow connection.

From my point of view, the overhead of the JVM is minimal in comparison. How much "overhead" (i.e. installed size) does Microsoft office take? Yet how many people use it? There's so much out of the box with the JRE (especially in Java 6 with derby, matisse & the gang) this 50MB download isn't an issue. Besides, with the open sourcing of Java, the JRE is more likely to appear on the standard images major PC manufacturers send out. My word, the Church is a large enough customer of Dell--start requesting the JRE put on all the machines you purchase. If that happens with enough other companies, the JRE will be more often pre-installed.

Again, look at all you can do out of the box with the JRE. That's a piece of software you won't have to tweak--you just distribute your app and say it requires the JRE. Done deal. It would be significantly more complex to say "well, here's the C++ code, and by the way you'll need packageA, and packageB, and packageC, and packageD and so on).

4. Language features - If you really are serious about "leaving behind" the mistakes of the past, and are serious about supporting multiple platforms, stay away from C++. You likely know as well as I how easy it is to write procedural code with C++. You should be writing this client not only as a proof of concept, but as an example to show others how to be successfully using your new API. Write it well, and write it in a language that more easily supports the principles of OOP. Yes, I'm fully aware that C++ supports OOP. And I'm also fully aware that the same program can have bits of C in it. Are you interested in hacky code, or are you interested in solid design?

5. Internet/networking support - Back to the API. What built-in (i.e. standard support) does C++ have in the internet/networking realm? Sure, you can get code to do ssh, or http or whatever, but is it part of the "standard" language? Nope. Java on the other hand--designed with the Internet in mind.

6. Portability - If the client were to be written in Java, you suddenly have cross platform support. No additional work on your end is required. If it were done in the C++ route, that would require you to suddenly be maintaining 3 (at least three) separate clients--one for the Mac, one for Windows, and one for Linux. Why write it three times (or at least maintain it three times) when you can do it once in java and be done with it?

For those living in the .NET world, C# is close enough to Java that it could easily be ported by anyone wishing to do that. However, the conversion from C++ to Java (or C#, for that matter) is more complicated.

7. Java is slow - I've found Java 6 to be significantly faster on Windows than previous versions (won't get into the political reasons between Sun and Microsoft here). Running Java on other OSes (say linux and OS X), speed has never been a problem.

From my point of view, any possible deterrent of using Java is FAR outweighed by its advantages. By the way, I'm not a Java bigot--I'm fully aware of .NET. However, I'm far more interested in using something open and cross platform by design (did I mention open?) with support on major OSes. While I agree that mono is cool (http://www.mono-project.org) and works remarkably well, it is done without any support from Microsoft at all. Heaven knows even with Microsoft support you're on shaky ground (Symantec, McAffee, Citrix anyone?), let alone without it. Besides, use of Java would make you more internally consistent as well (based on other presentations by the development folks in ICS).

Then again, there's always kde4 ([url]http://www.kde.org)[/url]...

[shoalcreek5]

3. "Grandma doesn't want a 50MB download for the JRE". What does the "typical user" get out of the box on their PC? They get Windows, along with the power of WordPad, Paint and calc. If they want some type of word processor or spreadsheet application, they're going to purchase something on a CD and install it (if they don't have a broadband connection). Or they'll be really patient and download it over their slow connection.

From my point of view, the overhead of the JVM is minimal in comparison. How much "overhead" (i.e. installed size) does Microsoft office take? Yet how many people use it? There's so much out of the box with the JRE (especially in Java 6 with derby, matisse & the gang) this 50MB download isn't an issue.

If Grandma buys a CD to get the new version of PAF and it is written in Java, it's fairly easy to include the new version of the different JRE's (Mac, Linux, Windows) on the CD and save her the download. This type of strategy has been commonly used with programs that require Adobe Reader to read the online manuals for the software

7. Java is slow - I've found Java 6 to be significantly faster on Windows than previous versions (won't get into the political reasons between Sun and Microsoft here). Running Java on other OSes (say linux and OS X), speed has never been a problem.

Although it is slightly slower than C++ and C, I've found through real-world timing tests that a well designed Java program will blow away anything in VisualBasic, which is commonly used by companies to make applications in Windows. Furthermore, certain types of problems can actually run almost as fast in Java as they do in C++. It has something to do with the amount of data being processed (greater amount of data up to a point depending on memory available=more efficient processing by the JVM) and how the C++ compiler handles memory/cpu cache versus how the JVM handles memory/cpu cache. For any given piece of code, various C++ compilers will produce various time/memory efficiency results on different systems. My point here is that for large data structures as is commonly encountered in Genealogy, the slow down by Java will be seen mostly at program initialization and will be small enough on a modern computer to be negligible to most end users. Once the program is running, the difference in processing time will be unnoticeable to anyone that is not timing the program with a timing utility that measures in thousandths of a second. In fact, a well designed java program might show a net speed increase over older versions of PAF. At any rate, it can and should be faster than the open source GRAMPS program on large genealogy databases. For example, my personal ancestry database has in the neighborhood of 100,000 nodes and GRAMPS takes MINUTES to traverse through and find an ancestor on my Linux machine (2.6 GHz P4, 1G pc400 memory in dual-channel configuration, intel d865perl mobo, 7200 rpm pata pc-133 disk drive). In contrast, the current version of PAF can do the same job in <10 seconds on my wife's Windows machine (AMD Athlon 2500+, 512mb pc400 memory in single channel, asus a7v880 mobo, 7200 rpm sata 1.0 disk drive).

[arxpoetica]

WOW there's a lot going over my head here, even though I like to think I'm savvy to the next gen of Web 2.0 apps. But I'm seriously grateful that the Church is willing to let the tech dept. head this way with open source and web presence. I wish I could have attended the Tech Talks.

Update: I think I just had a moment of prescience. Maybe one of the reasons the Church is letting this website exist (I know how dangerous forums can be out on the web -- sometimes the level of contention I have witnessed just astounds me) is that the Church was already making a push to move online in a serious way with the rise of Web 2.0 genealogy applications. After all, at least half of the miracle of the Internet is the miracle of enhanced communication. And of course this beta tech site becomes an excellent testing ground for how to proceed. Marvelous.

[thedqs]

I also fully support either way the programming platform goes. Another point for the Java implementation is that the API will also sponser people to create their own clients which could be written for platform dependance in C++, C#, VB, Assembly, or any other language.
This means that the church should give a basic application that can be executed on any platform and have 3rd-party devs add their improvements and/or make it platform dependent.