Hi Victor. I'm guessing you've downloaded one of the recent builds, and have taken a look.
From the end-user's viewpoint, there seems to be little different. The indi-page has a new side-bar thingummy. The themes are different. Some of the config pages have been tidied up.
All the real change is happening "under the hood".
PGV is a very mature system, and loads of features have been "grafted on". In order not to disturb any existing code/users/functionality, people just add more and more and more.
The result is a convoluted mess that is inefficient and difficult to support/maintain/develop.
Did you know that PGV has four different module interfaces (to support about 10 modules!).
We now have one - and it is the same module interface that is used to manage other plugins, such as reports, themes, etc.
PGV stores its data in a mix of files and database tables. This is due to its heritage as a file-based application. This leads to all sorts of problems when you need to synchronise edits. For example, moving pending changes from a file to database table. webtrees is database only. This lets us use database transactions, etc. to ensure that any edits/updates won't leave any half-completed changes. (A regular occurrence on PGV with large systems).
The translation system in PGV basically sucked. It works OK for english, but support for other languages is virtually non existant. We are using an (industry standard) system called gettext, which has lots of great features. Best of all is an on-line system to allow translators to contribute. PGV is 100% translated into english - all other languages are only partially supported. In webtrees, we now have 100% translation into german, italian and polish - with other languages rapidly catching up. Not bad for an application that hasn't even been released!
It is impossible to performance tune a "generic" database application. So, we're restricting ourselves to just MySQL v5.
Oh, and we're taking this opportunity to change a load of things that would be hard to "upgrade" in PGV. The privacy logic and pending updates in particular. The design of these is highly restrictive, and constrains pretty much every aspect of PGV. We have a replacement for this that is flexible, scalable, etc.
Next, we're trying to reduce the server footprint. My aim is to be able to run any size gedcom on a server with 32MB memory and a 30 second execution limit, within safe-mode and any other common server restrictions.
All these are things you won't notice as a user, but you'll appreciate when your gedcom hits 100,000 individuals!
Greg
