Server/client in genealogy?

[Ove]

Hello,

Im making a genealogy software that allows users of it to connect to
eachother and all data added will be sent to all logged on, does anyone know
about other genealogy software that have this feature?

Ove

[Robert Melson]

In article <[email protected]>,
"Ove" <[email protected]> writes:

Hello,

Im making a genealogy software that allows users of it to connect to
eachother and all data added will be sent to all logged on, does anyone know
about other genealogy software that have this feature?

Ove

Not quite the same, but you might look at phpGedView and (?) TNG. Both are
php-based applications which allow multiple users to do "collaborative
genealogy". Info on phpGedView is available at:
http://phpgedview.sourceforge.net/

HTH,
Bob Melson

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"One of the greatest delusions in the world is the hope that the evils in this world are to be cured by legislation." Thomas Reed
-----

[Dennis Lee Bieber]

On Sun, 26 Feb 2006 21:39:56 +0100, "Ove" <[email protected]> declaimed
the following in soc.genealogy.computing:

Hello,

Im making a genealogy software that allows users of it to connect to
eachother and all data added will be sent to all logged on, does anyone know
about other genealogy software that have this feature?

Anything that doesn't use a dedicated single person database engine

for the backend <G> should be capable... As long as the database is
always online, and the users only run a presentation/data-entry client.

But it sounds like you want to replicate the data on each user's
machine without having a central database server.

That is going to be very difficult to do, efficiently. You would
likely have to assign a GUID to every user's data entry. You'd still
need a central server to track who is connected, and on a log-in
transfer the GUIDs of all records from the new login to ALL the other
logged in clients so their software can determine if they are missing
any data (which would then have to be requested from the new log-in).
Similarly, each previous client will have to determine which GUIDs it
has that the new log-in did not send, and send those to the new log-in.
Of course, this could mean that many connected nodes will be sending the
SAME data to the new log-in, and the new log-in will have to reject all
but the first (ie, the first copy of a GUID/data arrives, and gets
stored; when the same GUID arrives again, the client sees it has that
data, and ignores it). LOTS of network traffic every time someone
connects. You also have the problem of handling conflicts -- if some one
edits a record, the GUID should not change; but how do you inform all
others that the data has to be updated? Guess you need to send ALL GUIDs
and a Last-Edit date to all other clients... And that doesn't help if
two people add the same person independently -- as both clients will
generate GUIDs, the system will treat them as two separate people.


{GUID, if you're not familiar with the acronym, is Globally Unique
IDentifier. While practically all DBMS have a means to generate a unique
incrementing index for data records, you need to have a way to identify
records from multiple sources -- so you have something like a
client-generated unique increment [which is not global, each client just
increments its own counter] and preface it with something unique -- like
the CPU serial number and/or the NIC MAC address. But now you get into
privacy concerns, as all data is tagged as to source machine.}



With a centralized database server, you reduce all that overhead of
sending duplicate data around. You only need to ensure transactional
locking so that only one person can update a set of tables at a time --
that is, if two people are editing PersonX, the first one submitted
should update the data, the second one should (as a stored procedure or
other backend logic) find that the data was changed during the edit, and
refuse to update. This could be done by having a last changed datestamp
as part of every record. When a client (User1) retrieves a record, the
datestamp goes with it (but is not visible to the user). On a submit, as
part of a single locked transaction, the backend first compares the
incoming datestamp (which records the original data currency) with the
datestamp that is in the database -- if they are the same, a new
datestamp is created and the update proceeds; otherwise, it means
someone (User2) has also been editing and submitted their changes before
User1 did. A failure report should be sent to User1 showing the new data
in the record along with what they wanted to put into the record.

You could even create a middleware client -- using a webbrowser as
the user client, and the middleware to manage sending forms to the user,
retrieving user data and sending it to the DBMS backend. This scheme has
some features you may find desirable. If the DBMS is the backend, and
the user client is directly accessing, you need some way to put
account/password access on the DBMS, and are still open to malicious
attacks as someone with the needed access (and you'd need to give
clients read/modify/insert, and maybe delete capability) could write a
program to do direct DBMS access. Using the middleware, the web
application, running on the webserver, is the only program that needs
DBMS access. User's only connect to the webserver application, which can
use a different protection scheme. It also means you could swap out the
DBMS for another and only have to modify the middleware application to
access the new DBMS -- no changes visible to the clients.


Take a look at "The Next Generation", a MySQL/PHP system.
--

==============================================================
[email protected] | Wulfraed Dennis Lee Bieber KD6MOG
[email protected] | Bestiaria Support Staff
==============================================================
Home Page: <http://www.dm.net/~wulfraed/
Overflow Page: <http://wlfraed.home.netcom.com/

[T.M. Sommers]

Dennis Lee Bieber wrote:

On Sun, 26 Feb 2006 21:39:56 +0100, "Ove" <[email protected]> declaimed
the following in soc.genealogy.computing:

Hello,

Im making a genealogy software that allows users of it to connect to
eachother and all data added will be sent to all logged on, does anyone know
about other genealogy software that have this feature?

Anything that doesn't use a dedicated single person database engine
for the backend <G> should be capable... As long as the database is
always online, and the users only run a presentation/data-entry client.

But it sounds like you want to replicate the data on each user's
machine without having a central database server.

That is going to be very difficult to do, efficiently. You would
likely have to assign a GUID to every user's data entry. You'd still
need a central server to track who is connected, and on a log-in
transfer the GUIDs of all records from the new login to ALL the other
logged in clients so their software can determine if they are missing
any data (which would then have to be requested from the new log-in).

I wonder about the possibility of using something like CVS to
track GEDCOMs. Suppose everyone working on a single database
imported checked-out GEDCOMs, and then checked in exported
GEDCOMs with their revisions. Probably everyone would have to
use the same program, because different programs are likely to
export GEDCOM nodes in different orders, which would confuse CVS.
Size might also be an issue. Perhaps a GEDCOM-specific
repository that knew enough GEDCOM not to be confused by
reordering. The advantage would be that one could work off-line,
yet still keep up to date, and keep others up to date.

--
Thomas M. Sommers -- [email protected] -- AB2SB

[Ove]

Hello, and thank you very much for a very interesting article. You point out
all that i have been wondering about. I do programming as a hobby and am
just in the learning fase of Server/Client apps but its the most
interesting part
of programming i ever seen... except objectprogramming when that was new and
hot.

I have already wroted some lines for this. If it is accetable and a
good choice, well, maybee it will be more clear in the future with lots of
testing...

The way I do it is very simple.... The app can be run as a server or client.
I use two collections which hold objects of the class TPerson and TFamily
and each time a user click "OK" to save edits or create a new person or
family the client send a message to the server that in turn send it to all
clients except that one who sent it. The client app then try to find that
person or family in the local collection, if found it update the data, if
not it create a new person or family. The server is asked for NextID for
families but for persons I found that it was practical to have ID
series....each user set his NextID he want to use for persons...(the server
could choose and set this automatically as soon a new user log in) Each user
use his own ID serie.. if he runs out of numbers... he just get a new serie
from the server.. this way its easy for him to see the last one he added...
(of course it could be done in many others ways). If two or more edit same
person or family....well, to be true I havent yet been considering that
problem, but as it work now.... the data for a person or family will be
updated each time a click is done on "OK" for all users but if another user
have up for editing the same person, the data that will be shown for that
person will not be changed because the data is updated for the object in the
collection for persons, im not quite sure how to make this better... but the
timestamp you described was interesting.... and maybee the best way.

The app im working on can be found at
http://home.online.no/~ovkjaer/agetoage.cfm
It can't open every GEDCOM file, it has to be in clean ASCII format.

Sincerely
Ove


"Dennis Lee Bieber" <[email protected]> skrev i melding
news:[email protected]...

On Sun, 26 Feb 2006 21:39:56 +0100, "Ove" <[email protected]> declaimed
the following in soc.genealogy.computing:

Hello,

Im making a genealogy software that allows users of it to connect to
eachother and all data added will be sent to all logged on, does anyone
know
about other genealogy software that have this feature?

Anything that doesn't use a dedicated single person database engine
for the backend <G> should be capable... As long as the database is
always online, and the users only run a presentation/data-entry client.

But it sounds like you want to replicate the data on each user's
machine without having a central database server.

That is going to be very difficult to do, efficiently. You would
likely have to assign a GUID to every user's data entry. You'd still
need a central server to track who is connected, and on a log-in
transfer the GUIDs of all records from the new login to ALL the other
logged in clients so their software can determine if they are missing
any data (which would then have to be requested from the new log-in).
Similarly, each previous client will have to determine which GUIDs it
has that the new log-in did not send, and send those to the new log-in.
Of course, this could mean that many connected nodes will be sending the
SAME data to the new log-in, and the new log-in will have to reject all
but the first (ie, the first copy of a GUID/data arrives, and gets
stored; when the same GUID arrives again, the client sees it has that
data, and ignores it). LOTS of network traffic every time someone
connects. You also have the problem of handling conflicts -- if some one
edits a record, the GUID should not change; but how do you inform all
others that the data has to be updated? Guess you need to send ALL GUIDs
and a Last-Edit date to all other clients... And that doesn't help if
two people add the same person independently -- as both clients will
generate GUIDs, the system will treat them as two separate people.


{GUID, if you're not familiar with the acronym, is Globally Unique
IDentifier. While practically all DBMS have a means to generate a unique
incrementing index for data records, you need to have a way to identify
records from multiple sources -- so you have something like a
client-generated unique increment [which is not global, each client just
increments its own counter] and preface it with something unique -- like
the CPU serial number and/or the NIC MAC address. But now you get into
privacy concerns, as all data is tagged as to source machine.}



With a centralized database server, you reduce all that overhead of
sending duplicate data around. You only need to ensure transactional
locking so that only one person can update a set of tables at a time --
that is, if two people are editing PersonX, the first one submitted
should update the data, the second one should (as a stored procedure or
other backend logic) find that the data was changed during the edit, and
refuse to update. This could be done by having a last changed datestamp
as part of every record. When a client (User1) retrieves a record, the
datestamp goes with it (but is not visible to the user). On a submit, as
part of a single locked transaction, the backend first compares the
incoming datestamp (which records the original data currency) with the
datestamp that is in the database -- if they are the same, a new
datestamp is created and the update proceeds; otherwise, it means
someone (User2) has also been editing and submitted their changes before
User1 did. A failure report should be sent to User1 showing the new data
in the record along with what they wanted to put into the record.

You could even create a middleware client -- using a webbrowser as
the user client, and the middleware to manage sending forms to the user,
retrieving user data and sending it to the DBMS backend. This scheme has
some features you may find desirable. If the DBMS is the backend, and
the user client is directly accessing, you need some way to put
account/password access on the DBMS, and are still open to malicious
attacks as someone with the needed access (and you'd need to give
clients read/modify/insert, and maybe delete capability) could write a
program to do direct DBMS access. Using the middleware, the web
application, running on the webserver, is the only program that needs
DBMS access. User's only connect to the webserver application, which can
use a different protection scheme. It also means you could swap out the
DBMS for another and only have to modify the middleware application to
access the new DBMS -- no changes visible to the clients.


Take a look at "The Next Generation", a MySQL/PHP system.
--
==============================================================
[email protected] | Wulfraed Dennis Lee Bieber KD6MOG
[email protected] | Bestiaria Support Staff
==============================================================
Home Page: <http://www.dm.net/~wulfraed/
Overflow Page: <http://wlfraed.home.netcom.com/

[Gjest]

Im making a genealogy software that allows users of it to connect to
eachother and all data added will be sent to all logged on, does anyone know
about other genealogy software that have this feature?

We have been using a server/client genealogy program for the last 6
years, as it was considered the only possible way to create our
country-wide database. This is not an application that is commercially
available - it was custom written for our needs. Basically it involves
a sentral data server, running Oracle with the client being a Java
application providing the front end. Everyone is then working on the
same database at the same time, with careful locking to prevent
problems if two people attmpt to modify the same entry at the same
time.