GDBI 12 and cvs slower than previous versions

Developers
2005-07-15
2013-04-24
  • John Finlay
    John Finlay
    2005-07-15

    I've noticed that recent versions of GDBI have been much slower than previous versions.  Before I starting modifying code to make this better I wanted to show you what I have found and see what you think.  I didn't see this behavior in version 11.

    See the debug info below, which first runs when connecting to a PGV site:
    [java] db.pgvcgi.CgiAccess: url action=version
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: url action=version
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: url action=listgedcoms
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: url action=version
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: url action=connect&username=john&password=xxxx
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: url action=getvar&var=READ_ONLY
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: getvar: READ_ONLY = 0
    [java] db.pgvcgi.CgiAccess: url action=version&ged=test.ged
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: url action=getvar&var=CHARACTER_SET
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: getvar: CHARACTER_SET = UTF-8
    [java] db.pgvcgi.CgiAccess: url action=getvar&var=GEDCOM
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: getvar: GEDCOM = test.ged
    [java] db.pgvcgi.CgiAccess: url action=getxref&type=INDI&position=all
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    [java] db.pgvcgi.CgiAccess: url action=getxref&type=FAM&position=all
    [java] db.pgvcgi.CgiAccess: status = SUCCESS
    [java] db.pgvcgi.CgiAccess:

    First I wonder why there are 4 requests to get the version when first connecting to a PGV site.  Wouldn't it be better to get the version once and store the value locally?

    Second, it is nice to have the stats of how many indis and fams are in a site, but on a larger site calling action=getxref&type=INDI&position=all returns a list of all of the IDs of the people on the gedcom.  I have almost 7000 people in my gedcom.  Assuming an average ID length of 5 bytes (ie INNNN) per ID, that is about 35K.  Now that is probably not unreasonable, but for larger gedcoms of say 100,000 people with an average ID of 6 bytes it is now about 600K being transferred just to load up the gedcom.

    Would it be helpful to add a new action to PGV that would return the number of individuals, families, and sources that are in the gedcom?  Something like:
    action=stats
    SUCCESS
    INDI    7000
    FAMS    4000
    SOUR    100

    Perhaps you use all of the IDs to create the mini-recs that you can then use to parse the tree?  In which case this wouldn't be helpful.

    The next thing I've noticed is now when I start BKEdit it first gets the PEDIGREE_ROOT_ID and then downloads tons of records... see this debug log:
         [java] db.pgvcgi.CgiAccess: url action=getvar&var=PEDIGREE_ROOT_ID
         [java] db.pgvcgi.CgiAccess: status = SUCCESS
         [java] db.pgvcgi.CgiAccess:

         [java] db.pgvcgi.CgiAccess: getvar: PEDIGREE_ROOT_ID = I1
         [java] db.pgvcgi.CgiAccess: url action=get&xref=I2304;I2303;I2302;I2301;I2300;F1199;F1198;F1197
    ;F1196;F1195;F1194;F1193;F1192;F1191;F1190;I1899;I1898;I1897;I1896;I1895;I1894;I1893;F1229;I1892;F12
    28;I1891;F1227;I1890;F1226;F1225;F1224;F1223;F1222;F1189;F1221;F1188;F1220;F1187;F1186;F1185;F1184;F
    1183;F1182;F1181;F1180;I1889;I1888;I1887;I1886;I1885;I1884;I1883;F1219;I1882;F1218;I1881;F1217;I1880
    ;F1216;F1215;F1214;F1213;F1212;F1179;F1211;F1178;F1210;F1177;F1176;F1175;F1174;F1173;F1172;F1171;F11
    70;I1879;I1878;I1877;I1876;I1875;I1874;I1873;F1209;I1872;F1208;I1871;F1207;I1870;F1206;F1205;F1204;F
    1203;F1202;F1169;F1201;F1168;F1200;F1167;F1166;F1165;F1164;F1163;F1162;F1161;F1160;I1869;I1868;I1867
    ;I1866;I1865;I1864;I1863;I1862;I1861;I1860;F1159;F1158;F1157;F1156;F1155;F1154;F1153;F1152;F1151;F11
    50;I1859;I1858;I1857;I1856;I1855;I1854;I1853;I1852;I1851;I1850;F1149;F1148;I6760;F1147;F1146;F1145;F
    1144;F1143;F1142;F1141;F1140;I1849;I1848;I1847;I1846;I1845;I1844;I1843;I6759;I1842;I6758;I1841;I6757
    ;I1840;I6756;I6755;I6754;I6753;I6752;F1139;I6751;F1138;I6750;F1137;F1136;F1135;F1134;F1133;F1132;F11
    31;F1130;I1839;I1838;I1837;I1836;I1835;I1834;I1833;I6749;I1832;I6748;I1831;I6747;I1830;I6746;I6745;I
    6744;I6743;I6742;F1129;I6741;I6740;I1829;I1828;I1827;I1826;I1825;I1824;I1823;I6739;I1822;I6738;I1821
    ;I6737;I1820;I6736;I6735;I6734;I6733;I6732;I6699;I6730;I6697;I6696;F559;I6695;F558;I6694;F557;I6693;
    F556;I6692;F555;I6691;F554;I6690;F553;F552;F551;F550;I1819;I1818;I1817;I1816;I1815;I1814;I1813;I6729
    ;I1812;I6728;I1811;I6727;I1810;I6726;I6725;I6724;I6723;I6722;I6689;I6721;I6688;I6720;I6687;I6686;F54
    9;I6685;F548;I6684;F547;I6683;F546;I6682;F545;I6681;F544;I6680;F543;F542;F541;F540;I1809;I1808;I1807
    ;I1806;I1805;I1804;I1803;I6719;I1802;I6718;I1801;I6717;I1800;I6716;I6715;I6714;I6713;I6712;I6679;I67
    11;I6678;I6710;I6677;I6676;F539;I6675;F538;I6674;F537;I6673;F536;I6672;F535;I6671;F534;I6670;F533;F5
    32;F499;F531;F498;F530;F497;F496;F495;F494;F493;F492;F491;F490;I6709;I6708;I6707;I6706;I6705;I6704;I
    6703;I6702;I6669;I6701;I6668;I2399;I6700;I6667;I2398;I6666;F529;I2397;I6665;F528;I2396;I6664;F527;I2
    395;I6663;F526;I2394;I6662;F525;I2393;I6661;I2392;F524;I6660;I2391;F523;I2390;F522;F489;F521;F488;F5
    20;F487;F486;F485;F484;F483;F482;F481;F480;I2389;I2388;I2387;F519;I2386;F518;I2385;F517;I2384;F516;I
    2383;F515;I2382;F514;I2381;F513;I2380;F512;F479;F511;F478;F510;F477;F476;F475;F474;F473;F472;F471;F4
    70;I2379;I2378;I2377;F509;I2376;F508;I2375;F507;I2374;F506;I2373;F505;I2372;F504;I2371;F503;I2370;F5
    02;F469;F501;F468;F500;F467;F466;F465;F464;F463;F462;F461;F460;I2369;I2368;I2367;I2366;I2365;I2364;I
    2363;I2362;I2361;I2360;I2359;I2358;I2357;I2356;I2355;I2354;I2353;I2352;I2351;I2350;I2349;I2348;I2347
    ;I2346;I2345;I2344;I2343;I2342;I2341;I2340;I2339;I2338;I2337;I2336;I2335;I2334;I2333;I2332;I2331;I23
    30;I2329;I2328;I2327;I2326;I2325;I2324;I2323;I2322;I2321;I2320;I2319;I2318;I2317;I2316;I2315;I2314;I
    2313;I2312;I2311;I2310;I1;I2309;I2308;I2307;I2306;I2305
         [java] db.pgvcgi.CgiAccess: status = SUCCESS

    There are 500 records in this request.  The first person it asks for is I2304.  I2304 is 14 steps away for person I1.  See http://www.finlayfamily.org/genealogy/relationship.php?pid1=I1&show_full=1&showfull=0&pretty=2&followspouse=1&pid2=I2304

    The immediate family members of I1 are not even in the list of requested IDs?????

    There are then two more very large requests:
         [java] db.pgvcgi.CgiAccess: url action=get&xref=I2269;I2268;I2267;I2266;I2265;I2264;I2263;I2262
    ;I2261;I2260;I2259;I2258;I2257;I2256;I2255;I2254;I2253;I2252;I2251;I2250;I2249;I2248;I2247;I2246;I22
    45;I2244;I2243;I2242;I2241;I2240;F1;I2239;I2238;I2237;I2236;I2235;I2234;I2233;I2232;I2231;I2230;I99;
    I98;I97;I96;I95;I94;I93;I92;I2229;I91;I2228;I90;I2227;I2226;I2225;I2224;I2223;I2222;I2221;I2220;I89;
    I88;I87;I86;I85;I84;I83;I82;I2219;I81;I2218;I80;I2217;I2216;I2215;I2214;I2213;I2212;I2211;I2210;I79;
    I78;I77;I76;I75;I74;I73;I72;I2209;I71;I2208;I70;I2207;I2206;I2205;I2204;I2203;I2202;I2201;I2200;I69;
    I68;I67;I66;I65;I64;I63;I62;I61;I60;I59;I58;I57;I56;I55;I54;I53;I52;I51;I50;F1099;F1098;F1097;F1096;
    F1095;F1094;F1093;F1092;F1091;F1090;I1799;I1798;I1797;I1796;I1795;I1794;I1793;I1792;F1128;I1791;F112
    7;I1790;F1126;F1125;F1124;F1123;F1122;F1089;F1121;F1088;F1120;F1087;F1086;F1085;F1084;F1083;F1082;F1
    081;F1080;I1789;I1788;I1787;I1786;I1785;I1784;I1783;F1119;I1782;F1118;I1781;F1117;I1780;F1116;F1115;
    F1114;F1113;F1112;F1079;F1111;F1078;F1110;F1077;F1076;F1075;F1074;F1073;F1072;F1071;F1070;I1779;I177
    8;I1777;I1776;I1775;I1774;I1773;F1109;I1772;F1108;I1771;F1107;I1770;F1106;F1105;F1104;F1103;F1102;F1
    069;F1101;F1068;F1100;F1067;F1066;F1065;F1064;F1063;F1062;F1061;F1060;I1769;I1768;I1767;I1766;I1765;
    I1764;I1763;I1762;I1761;I1760;F1059;F1058;F1057;F1056;F1055;F1054;F1053;F1052;F1051;F1050;I1759;I175
    8;I1757;I1756;I1755;I1754;I1753;I1752;I1751;I1750;F1049;F1048;F1047;F1046;F1045;F1044;F1043;F1042;F1
    041;F1040;I1749;I1748;I1747;I1746;I1745;I1744;I1743;I6659;I1742;I6658;I1741;I6657;I1740;I6656;I6655;
    I6654;I6653;I6652;I6651;I6650;I1739;I1738;I1737;I1736;I1735;I1734;I1733;I6649;I1732;I6648;I1731;I664
    7;I1730;I6646;I6645;I6644;I6643;I6642;I6641;I6640;I1729;I1728;I1727;I1726;I1725;I1724;I1723;I6639;I1
    722;I6638;I1721;I6637;I1720;I6636;I6635;I6634;I6633;I6632;I6599;I6631;I6598;I6630;I6597;I6596;F459;I
    6595;F458;I6594;F457;I6593;F456;I6592;F455;I6591;F454;I6590;F453;F452;F451;F450;I1719;I1718;I1717;I1
    716;I1715;I1714;I1713;I6629;I1712;I6628;I1711;I6627;I1710;I6626;I6625;I6624;I6623;I6622;I6589;I6621;
    I6588;I6620;I6587;I6586;F449;I6585;F448;I6584;F447;I6583;F446;I6582;F445;I6581;F444;I6580;F443;F442;
    F441;F440;F2838;I1709;I1708;I1707;I1706;I1705;I1704;I1703;I6619;I1702;I6618;I1701;I6617;I1700;I6616;
    I6615;I6614;I6613;I6612;I6611;I6610;F439;F438;F437;F436;F435;F434;F433;F432;F399;F431;F398;F430;F397
    ;F396;F395;F394;F393;F392;F391;F390;I6609;I6608;I6607;I6606;I6605;I6604;I6603;I6602;I6601;I6600;I229
    9;I2298;F429;I2297;F428;I2296;F427;I2295;F426;I2294;F425;I2293;F424;I2292;F423;I2291;F422;I2290;F389
    ;F421;F388;F420;F387;F386;F385;F384;F383;F382;F381;F380;I2289;I2288;F419;I2287;F418;I2286;F417;I2285
    ;F416;I2284;F415;I2283;F414;I2282;F413;I2281;F412;I2280;F379;F411;F410;I2279;I2278;F409;I2277;F408;I
    2276;F407;I2275;F406;I2274;F405;I2273;F404;I2272;F403;I2271;F402;I2270;F401;F400
         [java] db.pgvcgi.CgiAccess: status = SUCCESS
         [java] db.pgvcgi.CgiAccess:

         [java] db.pgvcgi.CgiAccess: url action=get&xref=I1625;I1624;I1623;I6539;I1622;I6538;I1621;I6537
    ;I1620;I6536;I6535;I6534;I6533;I6532;I6499;I6531;I6498;I6530;I6497;I6496;F359;I6495;F358;I6494;F357;
    I6493;F356;I6492;F355;I6491;F354;I6490;F353;F352;F351;F350;I1619;I1618;I1617;I1616;I1615;I1614;I1613
    ;I6529;I1612;I6528;I1611;I6527;I1610;I6526;I6525;I6524;I6523;I6522;I6489;I6521;I6488;I6520;I6487;I64
    86;F349;I6485;F348;I6484;F347;I6483;F346;I6482;F345;I6481;F344;I6480;F343;F342;F341;F340;I1609;I1608
    ;I1607;I1606;I1605;I1604;I1603;I6519;I1602;I6518;I1601;I6517;I1600;I6516;I6515;I6514;I6513;I6512;I64
    79;I6511;I6478;I6510;I6477;I6476;F339;I6475;F338;I6474;F337;I6473;F336;I6472;F335;I6471;F334;I6470;F
    333;F332;F299;F331;F298;F330;F297;F296;F295;F294;F293;F292;F291;F290;I6509;I6508;I6507;I6506;I6505;I
    6504;I6503;I6502;I6501;I6500;I2199;I2198;F329;I2197;F328;I2196;F327;I2195;F326;I2194;F325;I2193;F324
    ;I2192;F323;I2191;F322;I2190;F289;F321;F288;F320;F287;F286;F285;F284;F283;F282;F281;F280;I2189;I2188
    ;F319;I2187;F318;I2186;F317;I2185;F316;I2184;F315;I2183;F314;I2182;F313;I2181;F312;I2180;F279;F311;F
    278;F310;F277;F276;F275;F274;F273;F272;F271;F270;I2179;I2178;F309;I2177;F308;I2176;F307;I2175;F306;I
    2174;F305;I2173;F304;I2172;F303;I2171;F302;I2170;F269;F301;F268;F300;I2169;I2168;I2167;I2166;I2165;I
    2164;I2163;I2162;I2161;I2160;I2159;I2158;I2157;I2156;I2155;I2154;I2153;I2152;I2151;I2150;I2149;I2148
    ;I2147;I2146;I2145;I2144;I2143;I2142;I2141;I2140;I49;I48;I47;I46;I45;I44;I43;I42;I41;I40;I2139;I2138
    ;I2137;I2136;I2135;I2134;I2133;I2132;I2131;I2130;I39;I38;I37;I36;I35;I34;I33;I32;I31;I30;I2129;I2128
    ;I2127;I2126;I2125;I2124;I2123;I2122;I2121;I2120;I29;I28;I27;I26;I25;I24;I23;I22;I21;I20;I2119;I2118
    ;I2117;I2116;I2115;I2114;I2113;I2112;I2111;I2110;I19;I18;I17;I16;I15;I14;I13;I12;I11;I10;I2109;I2108
    ;I2107;I2106;I2105;I2104;I2103;I2102;I2101;I2100;F1039;F1038;F1037;F1036;F1035;F1034;F1033;F1032;F10
    31;F1030;I1699;I1698;I1697;I1696;I1695;I1694;I1693;F1029;I1692;F1028;I1691;F1027;I1690;F1026;F1025;F
    1024;F1023;F1022;F1021;F1020;I1689;I1688;I1687;I1686;I1685;I1684;I1683;F1019;I1682;F1018;I1681;F1017
    ;I1680;F1016;F1015;F1014;F1013;F1012;F1011;F1010;I1679;I1678;I1677;I1676;I1675;I1674;I1673;F1009;I16
    72;F1008;I1671;F1007;I1670;F1006;F1005;F1004;F1003;F1002;F1001;F1000;I1669;I1668;I1667;I1666;I1665;I
    1664;I1663;I6579;I1662;I6578;I1661;I6577;I1660;I6576;I6575;I6574;I6573;I6572;I6571;I6570;I1659;I1658
    ;I1657;I1656;I1655;I1654;I1653;I6569;I1652;I6568;I1651;I6567;I1650;I6566;I6565;I6564;I6563;I6561;I65
    60;I1649;I1648;I1647;I1646;I1645;I1644;I1643;I6559;I1642;I6558;I1641;I6557;I1640;I6556;I6555;I6554;I
    6553;I6552;I6551;I6550;F378;F377;F376;F375;F374;F373;F372;F371;F370;I1639;I1638;I1637;I1636;I1635;I1
    634;I1633;I6549;I1632;I6548;I1631;I6547;I1630;I6546;I6545;I6544;I6543;I6542;I6541;I9;I6540;I8;F369;I
    7;F368;I6;F367;I5;F366;I4;F365;I3;F364;I2;F363;F362;F361;F360;I1629;I1628;I1627;I1626
         [java] db.pgvcgi.CgiAccess: status = SUCCESS

    The immediate family members finally show up in the last request.  Assuming 500 individuals per request, that is 1500 people which is almost a quarter of my gedcom file.

    Now if I click on the button to move up to the root person's father I get two more large requests... another 1000 records downloaded.  Included in those requests are many of the same records that were already downloaded... including the root person I1!!!  We have just transferred megabytes of data and much of it was duplicate data we already downloaded.

    Now let say I go back down to the root person from the father's children tab.  It again downloads another large chunk of people (again including I1 who we are going back to and whose record we have downloaded 3 times now).

    And then, in the latest CVS an exception is thrown:
        [java] Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: net.sourceforge.gdbi
    editor.bk.ActionThread.dataFillNonNull(Lnet/sourceforge/gdbi/editor/bk/PersonFamily;)V
        [java]     at net.sourceforge.gdbi.editor.bk.BKPanelChildren$BKTableModelChildren.data_change_t
    _row(Unknown Source)
        [java]     at net.sourceforge.gdbi.editor.bk.BKPanelChildren$BKTableModelChildren.doMouseClick(
    nknown Source)
        [java]     at net.sourceforge.gdbi.editor.bk.BKTableModel$1.mouseClicked(Unknown Source)
        [java]     at java.awt.AWTEventMulticaster.mouseClicked(AWTEventMulticaster.java:212)
        [java]     at java.awt.Component.processMouseEvent(Component.java:5491)
        [java]     at javax.swing.JComponent.processMouseEvent(JComponent.java:3093)
        [java]     at java.awt.Component.processEvent(Component.java:5253)
        [java]     at java.awt.Container.processEvent(Container.java:1966)
        [java]     at java.awt.Component.dispatchEventImpl(Component.java:3955)
        [java]     at java.awt.Container.dispatchEventImpl(Container.java:2024)
        [java]     at java.awt.Component.dispatchEvent(Component.java:3803)
        [java]     at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
        [java]     at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3901)
        [java]     at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
        [java]     at java.awt.Container.dispatchEventImpl(Container.java:2010)
        [java]     at java.awt.Window.dispatchEventImpl(Window.java:1774)
        [java]     at java.awt.Component.dispatchEvent(Component.java:3803)
        [java]     at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
        [java]     at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:24
    )
        [java]     at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)

        [java]     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
        [java]     at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
        [java]     at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

     
    • Daniel Kionka
      Daniel Kionka
      2005-07-15

      This is great analysis!  I will have to read this over in detail, but I can make a few comments now.

      There is more chatter at the beginning because I am creating an object with the list of gedcoms.  I should be able to optimize that.

      You guessed right, I am reading the list of INDI and FAM IDs to create the mini-recs.  I didn't think about having 100,000 people, but we can start planning for that.  If I can defer creating the mini-recs, the action=stats would give us the info we need in the main window.

      I think the reason I created the mini-recs up front was to make it easier for integrating other applications, like Taurus FamilyTree.  Other apps tend to assume you can read in the entire gedcom at startup, usually from a text file.  The compromise was to create empty mini-recs at startup, with just the ID, and create the real records later.  All I needed was the list of all IDs to create the empty records.

      Once it gets the list of IDs, it starts to download the records in "reasonable" chunks.  It sounds like chunks of 500 are too big.  That is a 1-line change.  Note that in debug made the size is smaller to force more CGI interaction.

      Once it gets some records, it is supposed to start getting their close links.  If they are not at the front of the queue (and it just takes the long list of IDs first), I will have to fix that.

      If it is reloading records, it probably means my cache is too small.  That again is a 1-liner.  I was probably too conservative on space.  Also, the records expire, and we can tweak the time.

      Another thing we can do to improve things is to add a command to download mini-recs.  We discussed this a while back.  Right now I have to download the whole record to get the basic link info.  On the other hand, then I can't piggyback the immediate family requests on the same request to read in more mini-recs.

      What would probably be best is to have a separate thread that creates all mini-recs in parallel.  That way the editor can get right to the people you care about.  It sounds like data corruption waiting to happen, but synchronization is supposed to be easy with Java.  The main window could take care of the mini-rec caching in parallel to any app you run.

       
    • John Finlay
      John Finlay
      2005-07-15

      If you need to, you can test against my live site with an anonymous connection.  http://www.finlayfamily.org/genealogy/client.php

      Yes I remember talking about the mini-recs before.  Doing that would mean quite a bit of work on the server side to reduce the record to a mini rec.  It would reduce the amount of traffic, but the extra processing may mean that it isn't any faster than sending the whole record with the first request.  It also seems redundant to send part of a record when you are going to ask for the full record a few seconds later.  You end up sending more data than just sending the full record once.

      What I plan to add for the next release of PGV is synchronization actions such that you can cache the records you download in a file and only ask if the record changed since you last downloaded it.

      Another thing that we should look at doing eventually is sending the data back and forth in a compressed format.  This would be a little more secure and would save a lot of bandwidth.  It could be a parameter as part of the connect action.

      --John

       
    • Daniel Kionka
      Daniel Kionka
      2005-07-23

      I was thinking about the multiple version requests and the listgedcoms.  Yes, it is non-optimized coding, but I think we made the CGI commands too primitive.  The greatest cost is connecting across the network, so having to get the version to find out if I can get the gedcom list is a waste.

      What I propose is get-all-public-info command that would return the version, gedcoms, and anything else in the future.  Then for a given gedcom, instead of requesting individual variables, like READ_ONLY and CHARACTER_SET, we could have a get-all-variables command.  Both commands could return a list of name=value lines.

       
    • Daniel Kionka
      Daniel Kionka
      2005-07-23

      I got rid of 2 of the version requests.  You still see 2 that look redundant.  The first is from trying the URL as-is, without appending client.php.  The other is later when it sets the gedcom, since you have to run a dummy command to set a variable.

      I tried appending client.php first, since you hope people use the base URL, but to my surprise, it works when the URL is .../phpGedView/client.php/client.php.  I think the 2nd /client.php becomes a parameter to the script.  I think it is safer to use the URL as-is first.