Obvious Reason a Universal Database Structure isn't Optional
May 11, 2022 22:16:34 GMT -8
Post by Uncle Buddy on May 11, 2022 22:16:34 GMT -8
Let's say that having a lot of genieware vendors all trying to outdo each other is a good thing.
I'm not going to mention GEDCOM, except to say that under normal circumstances (i.e. if the import/export programs have not been both written by a GEDCOM savant), GEDCOM doesn't transfer data well. And unless the file is tiny, it never transfers data at the speed of computing.
So let's skip the rest of that rant and let's say that it's only right that Genieware A should be directly importable to Genieware B, and vice versa.
Now let's say that there are 26 usable family tree display & edit products out there, one for every letter of the alphabet.
How many import/export programs have to be written, and then updated every time one of these 26 vendors puts out a new version of their program?
26 x 26 = 676. That's 676 import programs and 676 export programs. 1352 data transfer programs. But there are a lot more than 26 apps out there.
This is why GEDCOM is still tolerated. (Sorry I said "GEDCOM".) It acts as an intermediary so we don't have to deal with writing dozens or hundreds of transfer programs to get people to buy our products.
The solution is neither simple nor easy to swallow, but it's obvious.
Geniewares A thru Z keep their GUI and their product identity, but start using a universal SQLite database structure to store data instead of whatever they're doing now.
This isn't something a company could phase in gradually. I suppose it would have to be a sudden change. It sounds like a nightmare of logistics, and users might have to do a lot of their work over, but once the pain subsides we will enter the golden age of sharing family trees.
Anyone know of any currently existing nightmares which we are putting up with in regards to data transfer?
I do, but I promised not to mention GEDCOM.
I'm not going to mention GEDCOM, except to say that under normal circumstances (i.e. if the import/export programs have not been both written by a GEDCOM savant), GEDCOM doesn't transfer data well. And unless the file is tiny, it never transfers data at the speed of computing.
So let's skip the rest of that rant and let's say that it's only right that Genieware A should be directly importable to Genieware B, and vice versa.
Now let's say that there are 26 usable family tree display & edit products out there, one for every letter of the alphabet.
How many import/export programs have to be written, and then updated every time one of these 26 vendors puts out a new version of their program?
26 x 26 = 676. That's 676 import programs and 676 export programs. 1352 data transfer programs. But there are a lot more than 26 apps out there.
This is why GEDCOM is still tolerated. (Sorry I said "GEDCOM".) It acts as an intermediary so we don't have to deal with writing dozens or hundreds of transfer programs to get people to buy our products.
The solution is neither simple nor easy to swallow, but it's obvious.
Geniewares A thru Z keep their GUI and their product identity, but start using a universal SQLite database structure to store data instead of whatever they're doing now.
This isn't something a company could phase in gradually. I suppose it would have to be a sudden change. It sounds like a nightmare of logistics, and users might have to do a lot of their work over, but once the pain subsides we will enter the golden age of sharing family trees.
Anyone know of any currently existing nightmares which we are putting up with in regards to data transfer?
I do, but I promised not to mention GEDCOM.