Re: [LAF-devel] Re: Design

[Wesley J L. <wj...@ic...>]

On Saturday 09 August 2003 11:03 pm, Samuel G. Shirley wrote:
> Hello Everyone,
> > > I wouldn't mind leading it if people understood that this would
> > > be a learning experience for me.
> >
> > Well, we can "co-lead" it if that sounds more palpable. ;)
>
> It would sort of be a learning experiece for me to. I'm a programmer
> by trade myself. I've been out of the industry for a couple of years
> because of the economy. I also haven't written anything good in a
> while. But I've writtten mostly a few small projects since college
> (Dec. 1999). Nothing with a group of people. So I'm looking to gain
> some experience and get my feet wet again.

Great! We can use help right now from anyone that is interested. =3D)

> > > I need Paf and GedCom compatability.  I think it would be great
> > > if we can fork something to be PAF compatible, however, I'm not
> > > overly optimistic about this.
>
> I agree with this. I've already tried a couple and I am not happy. I
> tried Genes (genes.sourceforge.net) and Gramps
> (gramps.sourceforge.net). Genes is not in a good working stage.
> Gramps looks very pretty and works pretty well. But there are too
> many quirks in it for me to be happy with it. Frankly, it's a pain. I
> like PAF. I personally would like to see a clone of it in Linux. This
> would also serve to make those moving from Win to Linux much happier.

I haven't tried any lately (which is why I suggested that we look at the=20
state of things now), but back when I tried them, most geneology=20
programs were sorely lacking.=20

In fact, even between PAF versions there have been quite a few changes=20
in usability! I know people who still prefer PAF 3. =3D)

Anyway, it sounds like between everyone here we've got the following=20
goals: (Correct me if I'm wrong. ;)
  - Be feature compatible with PAF. That is, support doing everything in=20
LAF that is doable in PAF.
  - Be file-format compatible with PAF. That is, support transferring=20
data with *no loss* between PAF and LAF. Whether this can be done with=20
GEDCOM or if it requires native file-format compatibility will have to=20
be determined.
  - Be familiar to PAF users. That is, our GUI should work as much like=20
PAF as makes sense.
  - Be *better* than PAF; be open and extendable. That is, if we can do=20
something better than PAF does it, or add new features that PAF lacks,=20
we should do it.

> > Question: how important is it to you to have PAF file-format=3D20
> > compatibility? GEDCOM is certainly no problem, but the PAF
> > database=3D20 files themselves have changed format in every version
> > of PAF and I=3D20 don't know if they are documented anywhere...
> > certainly we could=3D20 reverse-engineer them if it's worth it to.=3D20
>
> I think its important to have PAF compatibiilty. PAF is a big program
> with a large following. Our program should be able to AT LEAST import
> those files.

I agree that importing PAF native files is important, *even if* GEDCOM=20
round-tripping is possible without data loss. However, this may (or may=20
not) require some reverse-engineering effort. We might want to start=20
off with GEDCOM support, but out file I/O subsystem should be=20
pluggable. =3D)

=2D-=20
Wesley J. Landaker - wj...@ic...
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2