RE: [Phpgedview-talk] Some general questions from a newbie

[John F. <Joh...@by...>]

Hi James,

> At first I wasn't going to consider PGV, as the first material that I
found
> lauded it as not requiring mySQL, but I see that mySQL is an option.

The next version of PGV 3.3 will support MySQL, SQLite, and Postgres, as
well as the database free index mode.  Index mode will likely be phased
out as PHP 5 become more ubiquitous.  Technically Oracle should also be
available, but it has not been tested.

> In brief, I'd like to provide a service much like the One Great Family
> website, but either for free or for almost free. Also, I don't care
for
> their merging interface, nor their free-for-all merging resolution. It
> seems like they allow pairs of submitters to merge against each other
and
> to modify that pair's data. I'd like to have a master file and have
> submitters's data merged against it. Merge disputes would be
arbitrated.

Your complaints about One Great Family are the same ones that I have,
along with the fact that they don't keep much more information than
birth and death and that there is no privacy in their system.


> OK, that said, and knowing that if I knew how really difficult this
would
> be to implement, I'd give up the silly idea in a second, I'd still
like to
> ask those who know the software to fast track me about the obvious
> obstacles. I am a programmer, but not too advanced with php and still
> pretty clueless about OOP. I've learned just enough to build a dynamic
site
> with some authentication, session control, etc. I've recently
installed
> mediaWiki (same as used by WikiPedia) which uses php/mySQL, and have
been
> able to use it's "extension" markup tags to call php functions which
pass
> back HTML containing tables of data from my main site's mySQL. But
let's
> pretend that I have a team of competent php gurus in my back pocket.
How
> suitable is PGV as a starting place for modifying into what I
describe? How
> close is it already? I'll install it and play with it during the next
month
> regardless, but it would help if I knew in advance some of the
boundaries.

PGV is already pretty close to that.  What you don't currently have is
the ability for non-root users to upload their own gedcoms or manage
their own users.  But once a gedcom is uploaded administrative
privileges can be extended to other users. =20
=20
> Here are some of my initial fears:
> 1) there is a practical limit to the amount of data that can be
managed.

The practical limits for what you want to do will probably be based on
hardware constraints (ie available RAM, available hard disk, CPU power,
etc).  And then software constraints such as limits in MySQL.  I imagine
that you would be able to hold 2-3 million people (ie 500 average size
gedcoms) before you would have to start looking into clustering your
database and hardware.

> 2) there are too many fundamental design structures that would have to
be
> changed to allow the extra features

All you should have to do is make a few database changes to the users
table.

> 3) GEDCOM upload is manual? (If so, a module would have to be
developed to
> allow grandma to submit.)

Upload can be done online (depending again on server constraints) and is
a pretty simple process... though I don't think the average grandma
could do it without some training and instruction.  If you want to
support such basic users it would be better to have them upload their
gedcom to a temporary location and then you import it for them.

> 4) robustness issues with importing GEDCOMs from every possible source
and
> export scenario. If so, an import filter would need to be developed. I
> believe that this is already an issue, with a common solution to run
the
> file through a dependable application like Brother's Keeper to massage
the
> data into a more troublefree form?

PGV will handle almost all possible gedcoms that are close to the GEDCOM
spec.  The PGV philosophy has been to leave the original gedcom intact
as it comes in and then build all displays from the gedcom records.
This has produced a system that is extremely compatible with the GEDCOM
spec.

The real problems come from people not inputting valid data such as
dates and places.  Invalid data is still shown, but it can't be used in
any calculations such as the calendar.  Family Tree Maker is also
notorious for producing awkward gedcoms.  PGV already has a cleanup
script as part of the import process which will fix FTM gedcoms and some
other common gedcom problems.  You could extend this to do anything that
you wanted.

> 5) I would probably need to add data in a non-GEDCOM form. I assume
that
> uploading it directly into the mySQL tables wouldn't be too difficult?
It
> depends on how much the data is spread around in different tables, and
how
> relationships are managed. This data would probably be mostly events,
> without much connection to other records, like a list of births from a
> church book, eg.

PGV requires gedcom form since it stores the gedcom in the tables and
uses the gedcom record to build the displays.  The gedcom data is stored
in 4 tables, pgv_individuals, pgv_families, pgv_sources, and pgv_other.
So you will need to convert any data to gedcom first (not an impossible
task for most genealogy data).

You should definitely download the latest beta version 3.3 and play
around with it.

I'll be happy to answer any other questions you may have.

--John

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
John Finlay
PhpGedView Project Manager
ya...@us...