Thread: [LAF-devel] Re: Design
Status: Planning
Brought to you by:
dmbrown
Menu
▾
▴
laf-devel
|
From: Samuel G. S. <ssh...@cs...> - 2003-08-10 05:04:27
|
Hello Everyone, I had joined this nailing list a LONG time ago and even forgot about the project until somebody starting email again. :-) I'm glad that there is interest in working on this project again. > > 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. > > > One thing we might want to do is scope out other linux-based > > > geneology programs out there and make sure there isn't already > > > something that 1) already does everything we need and we just don't > > > realize it, or 2) could be forked to be PAF-compatible. I'd rather > > > not duplicate work unless it's necessary. =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. > Question: how important is it to you to have PAF file-format=20 > compatibility? GEDCOM is certainly no problem, but the PAF database=20 > files themselves have changed format in every version of PAF and I=20 > don't know if they are documented anywhere... certainly we could=20 > reverse-engineer them if it's worth it to.=20 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. > GUI: Of course, we need a GUI. This would be layered on top of the core,=20 > and thus we avoid mixing GUI and core logic. Again....PAF cloning would be nice. |
|
From: Wesley J L. <wj...@ic...> - 2003-08-10 21:25:56
|
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 |
|
From: David M. B. <da...@da...> - 2003-08-11 02:21:07
|
Thanks for starting to get goals into a list form. I like good, concise lists. :) I have a couple of comments here; let me know what you think. Wesley J Landaker wrote: > On Saturday 09 August 2003 11:03 pm, Samuel G. Shirley wrote: [...] >>>>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 > state of things now), but back when I tried them, most geneology > programs were sorely lacking. Ok, so my original idea for LAF was to be a PAF clone. This especially goes for both ends of the software usage (GUI and file format, the former being most important (as long as we don't get into trouble)). I wanted a PAF user to sit down and start using LAF from day one and not even know they were using LAF. Sure, there are going to be some subtle differences, but as much as is feasibly possible make it a PAF look-and-feel-alike. That was the first and foremost feature and all other features, as long as they don't detract from this first feature, would be considered. With that in mind... > In fact, even between PAF versions there have been quite a few changes > in usability! I know people who still prefer PAF 3. =) > > Anyway, it sounds like between everyone here we've got the following > goals: (Correct me if I'm wrong. ;) > - Be feature compatible with PAF. That is, support doing everything in > LAF that is doable in PAF. Right on! > - Be file-format compatible with PAF. That is, support transferring > data with *no loss* between PAF and LAF. Whether this can be done with > GEDCOM or if it requires native file-format compatibility will have to > be determined. Yup! > - Be familiar to PAF users. That is, our GUI should work as much like > PAF as makes sense. Even a little into the "does that really make sense?" realm should be done. In other words, there may be extra effort invovled (more than usual) to make it look like PAF so that PAF users are completely comfortable. > - Be *better* than PAF; be open and extendable. That is, if we can do > something better than PAF does it, or add new features that PAF lacks, > we should do it. Yes, but only to the extent that we don't take away from the PAF similarities. I'll admit there are things in PAF that I would have done differently, but there will be some things that we'll have to implement that we won't like just to make it familiar to PAF users. >>>Question: how important is it to you to have PAF file-format=20 >>>compatibility? GEDCOM is certainly no problem, but the PAF >>>database=20 files themselves have changed format in every version >>>of PAF and I=20 don't know if they are documented anywhere... >>>certainly we could=20 reverse-engineer them if it's worth it to.=20 >> >>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 > round-tripping is possible without data loss. However, this may (or may > not) require some reverse-engineering effort. We might want to start > off with GEDCOM support, but out file I/O subsystem should be > pluggable. =) Exactly. I'll start a list on SourceForge of the project goals as soon as I see a little more feedback on what we think the goals should be. Your email is a wonderful start (and is probably close to the finished list) for everyone to comment on. At least we have a few people now on the list who can comment (more than we had before), but the number is small enought that I'd hope everyone would comment. Thanks, David |
|
From: Wesley J L. <wj...@ic...> - 2003-08-10 21:26:22
|
On Sunday 10 August 2003 2:29 am, David M. Brown wrote: > Hey all. I'm glad someone poked my memory about this project. I > more or less had forgotten about it. :/ [ . . . ] > So, I think it would be helpful to get an idea of who has what > skills. This seems like it is already coming out in the emails so > far. It also helps to know who wants to do what. I don't mind doing > project management type stuff. But in order to do that I need lots > of feedback initially on who wants to do what. As far as skills and who-wants-to-do-what kinds of things, I can=20 probably help with the overall design, coding, managing CVS (I know how=20 to do just about anything you could ever want with CVS ;), and even=20 reverse-engineering PAF file formats if we need to do that. Basically,=20 I'm most interested in working hard to get a good infrastructure set=20 up, get a solid design, help build a framework, and then see how it=20 goes from there. ;) If I were going to pick tools to use on my own, I'd recommend: - C++ for the core - Qt for the GUI (and could be used as well for i.e. Unicode support) - db4 for the database (SQL might be okay too) - ruby as an embedded scripting language (if needed) What are others interested in using? Also, what license(s) are people thinking of releasing under?=20 Personally, I feel that it makes the most sense to release applications=20 under the GPL, as it guarantees that any changes made to the program=20 will stay as Free Software. > One last thing. I know a couple of people who work for the LDS > church software development department, but I'm not sure if they work > on PAF or not. They may be able to get me some information on PAF's > native file format, though. Heh, I once wrote to them a while back > about doing this project and getting what help we could from them, > and they were absolutely NOT interested. Maybe things will have > changed by now. It would sure be nice to get some info from them, but I think it might=20 be tough to get them to cough up much info. I believe PAF (at least the=20 later versions) was outsourced and much of the internals are really=20 proprietary. It's kind of sad, actually... But hey, hopefully I'm wrong=20 and they'll be more willing to give you some info this time around. ;) =2D-=20 Wesley J. Landaker - wj...@ic... OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 |
|
From: David M. B. <da...@da...> - 2003-08-11 02:25:56
|
This looks good. The only concern I've have in the past is with licensing of Sleepycat's Berkeley DB, but that was with projects that had some closed-source components. Since I'm hoping we can keep this all BSD licensed, this should be OK. I'm not very familiar with ruby. What are the advantages for using it as an embedded scripting language? Can you give an example or two of how it could be used as such? Thanks, David Wesley J Landaker wrote: > On Sunday 10 August 2003 2:29 am, David M. Brown wrote: > >>Hey all. I'm glad someone poked my memory about this project. I >>more or less had forgotten about it. :/ > > [ . . . ] > >>So, I think it would be helpful to get an idea of who has what >>skills. This seems like it is already coming out in the emails so >>far. It also helps to know who wants to do what. I don't mind doing >>project management type stuff. But in order to do that I need lots >>of feedback initially on who wants to do what. > > > As far as skills and who-wants-to-do-what kinds of things, I can > probably help with the overall design, coding, managing CVS (I know how > to do just about anything you could ever want with CVS ;), and even > reverse-engineering PAF file formats if we need to do that. Basically, > I'm most interested in working hard to get a good infrastructure set > up, get a solid design, help build a framework, and then see how it > goes from there. ;) > > If I were going to pick tools to use on my own, I'd recommend: > - C++ for the core > - Qt for the GUI (and could be used as well for i.e. Unicode support) > - db4 for the database (SQL might be okay too) > - ruby as an embedded scripting language (if needed) > > What are others interested in using? > > Also, what license(s) are people thinking of releasing under? > Personally, I feel that it makes the most sense to release applications > under the GPL, as it guarantees that any changes made to the program > will stay as Free Software. > > >>One last thing. I know a couple of people who work for the LDS >>church software development department, but I'm not sure if they work >>on PAF or not. They may be able to get me some information on PAF's >>native file format, though. Heh, I once wrote to them a while back >>about doing this project and getting what help we could from them, >>and they were absolutely NOT interested. Maybe things will have >>changed by now. > > > It would sure be nice to get some info from them, but I think it might > be tough to get them to cough up much info. I believe PAF (at least the > later versions) was outsourced and much of the internals are really > proprietary. It's kind of sad, actually... But hey, hopefully I'm wrong > and they'll be more willing to give you some info this time around. ;) > |
|
From: Wesley J L. <wj...@ic...> - 2003-08-12 00:02:31
|
On Sunday 10 August 2003 8:25 pm, David M. Brown wrote: > This looks good. The only concern I've have in the past is with > licensing of Sleepycat's Berkeley DB, but that was with projects that > had some closed-source components. Since I'm hoping we can keep this > all BSD licensed, this should be OK. Well, using BSD might be problematic... =46or databases: Sleepycat's license is GPL compatible (and obviously compatible with=20 itself) but it's not BSD compatible, because of clause #3: * 3. Redistributions in any form must be accompanied by information on * how to obtain complete source code for the DB software and any * accompanying software that uses the DB software. The source code * must either be included in the distribution or be available for no * more than the cost of distribution plus a nominal fee, and must be * freely redistributable under reasonable conditions. For an * executable file, complete source code means the source code for=20 all * modules it contains. It does not include source code for modules=20 or * files that typically accompany the major components of the=20 operating * system on which the executable file runs. * Likewise, MySQL support would be out, since that's GPL.=20 However, Postgresql *is* BSD licensed, so it could be used as a backend. =46or a GUI: Qt is GPL, so not BSD compatible. wxWindows, GTK, and FOX are all LGPL, as is libgedcom (which I was=20 hoping to use). While these wouldn't affect this work itself being BSD,=20 it does prohibit distribution of executables without also providing=20 full source code for all libraries linked against it. (In essence,=20 negating the difference between BSD and GPL). =2E.. Anyway, if we want to try to stay BSD, it might be tricky, but perhaps=20 could be done... personally, I think we might be better off going with=20 [L]GPL which would put quite a bit more free software at our disposal. Of course, we can also play games to get around some license=20 prohibitions by (for instance) modularizing things to run as separately=20 linked processes that communicate with well-documented sockets or=20 something. What is everyone's thoughts on this? I'm not against BSD, but it is=20 rather limiting from a consumer-of-free-software perspective. > I'm not very familiar with ruby. What are the advantages for using > it as an embedded scripting language? Can you give an example or two > of how it could be used as such? Well, ruby is a "scripting" language comparable in scope to perl or=20 python, except it's much more object-oriented, and, IMO, a much more=20 clean, intuitive language overall. It embeds as easily as perl or=20 python--usually using SWIG (http://www.swig.org/). Basically the advantage of having scripting language support would be =20 twofold. As a developer, you can implement some logic that annoying to=20 do in C++ in ruby (or perl, or python, or whatever). For example, if=20 you wanted to have a plugin that fetched data from www.ancestry.com or=20 www.familysearch.com, it would be several lines in a scripting language=20 (which has built in network support, easy string manipulation, etc,=20 etc) while writing it in a compiled language would probably mean the=20 pain of creating sockets, connecting them, creating buffers, reading=20 data, parsing it, etc. Second, that you could (as a user) write custom=20 scripts to "drive" the GUI (generate custom reports, link data into=20 another program, whatever). =2D-=20 Wesley J. Landaker - wj...@ic... OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 |
|
From: David M. B. <da...@da...> - 2003-08-12 01:18:21
|
Wesley J Landaker wrote: > On Sunday 10 August 2003 8:25 pm, David M. Brown wrote: > >>This looks good. The only concern I've have in the past is with >>licensing of Sleepycat's Berkeley DB, but that was with projects that >>had some closed-source components. Since I'm hoping we can keep this >>all BSD licensed, this should be OK. > > > Well, using BSD might be problematic... > > For databases: > > Sleepycat's license is GPL compatible (and obviously compatible with > itself) but it's not BSD compatible, because of clause #3: > > * 3. Redistributions in any form must be accompanied by information on > * how to obtain complete source code for the DB software and any > * accompanying software that uses the DB software. The source code > * must either be included in the distribution or be available for no > * more than the cost of distribution plus a nominal fee, and must be > * freely redistributable under reasonable conditions. For an > * executable file, complete source code means the source code for > all > * modules it contains. It does not include source code for modules > or > * files that typically accompany the major components of the > operating > * system on which the executable file runs. > * I don't see why this is a problem with the BSD license. In fact, Sleepycat gives the GPL and BSD license as two good examples of licenses which work with their license (at http://www.sleepycat.com/download/licensinginfo.shtml). Here is part of that page: The open source license for Berkeley DB permits you to use the software at no charge under the condition that if you use Berkeley DB in an application you redistribute, the complete source code for your application must be available and freely redistributable under reasonable conditions. Further down it mentions the BSD license, too. > > Likewise, MySQL support would be out, since that's GPL. I won't claim to be a license expert, but I'm fairly sure that BSD-licensed code can use GPLed code. Now that I think about it though, (one of) the point(s) of the GPL is to make sure code stays open, and BSD code can be closed later on. But, then that code can no longer use the GPLed code, right? I'll have to look more closely at it. My network connection is flaking out right now, so later... :/ > > However, Postgresql *is* BSD licensed, so it could be used as a backend. > > For a GUI: > > Qt is GPL, so not BSD compatible. > > wxWindows, GTK, and FOX are all LGPL, as is libgedcom (which I was > hoping to use). While these wouldn't affect this work itself being BSD, > it does prohibit distribution of executables without also providing > full source code for all libraries linked against it. (In essence, > negating the difference between BSD and GPL). > > ... > > Anyway, if we want to try to stay BSD, it might be tricky, but perhaps > could be done... personally, I think we might be better off going with > [L]GPL which would put quite a bit more free software at our disposal. > > Of course, we can also play games to get around some license > prohibitions by (for instance) modularizing things to run as separately > linked processes that communicate with well-documented sockets or > something. > > What is everyone's thoughts on this? I'm not against BSD, but it is > rather limiting from a consumer-of-free-software perspective. > > >>I'm not very familiar with ruby. What are the advantages for using >>it as an embedded scripting language? Can you give an example or two >>of how it could be used as such? > > > Well, ruby is a "scripting" language comparable in scope to perl or > python, except it's much more object-oriented, and, IMO, a much more > clean, intuitive language overall. It embeds as easily as perl or > python--usually using SWIG (http://www.swig.org/). > > Basically the advantage of having scripting language support would be > twofold. As a developer, you can implement some logic that annoying to > do in C++ in ruby (or perl, or python, or whatever). For example, if > you wanted to have a plugin that fetched data from www.ancestry.com or > www.familysearch.com, it would be several lines in a scripting language > (which has built in network support, easy string manipulation, etc, > etc) while writing it in a compiled language would probably mean the > pain of creating sockets, connecting them, creating buffers, reading > data, parsing it, etc. Second, that you could (as a user) write custom > scripts to "drive" the GUI (generate custom reports, link data into > another program, whatever). Yeah; maybe we can make extensions possible in a couple of different ways. Ruby sounds like a definite way to go. Is it fairly widely used? For my benefit can you give a couple of examples of where it's being used? Thanks, David > |
|
From: Wesley J L. <wj...@ic...> - 2003-08-17 20:52:29
|
On Monday 11 August 2003 7:13 pm, David M. Brown wrote: > Wesley J Landaker wrote: > > Well, using BSD might be problematic... > > Sleepycat's license is GPL compatible (and obviously compatible > > with itself) but it's not BSD compatible, because of clause #3: > I don't see why this is a problem with the BSD license. In fact, > Sleepycat gives the GPL and BSD license as two good examples of > licenses which work with their license (at > http://www.sleepycat.com/download/licensinginfo.shtml). Here is part > of that page: > > Likewise, MySQL support would be out, since that's GPL. > I won't claim to be a license expert, but I'm fairly sure that > BSD-licensed code can use GPLed code. Now that I think about it > though, (one of) the point(s) of the GPL is to make sure code stays > open, and BSD code can be closed later on. But, then that code can no > longer use the GPLed code, right? Basically, it's not a matter of any of the above licenses not working=20 together; you can combine BSD, Sleepycat and GPL code all you want and=20 that doesn't change the individual licenses of the code pieces. What=20 does happen, however, is that when you combine and distribute the code=20 together, you have to meet the conditions of *all* the licenses. So=20 that means that if you use a GPL'd library in a BSD program, the entire=20 work is not literally all GPL'd, but you have to meet the conditions of=20 the GPL if you distribute the program and the library together in any=20 form. Anyway, making LAF code itself BSD is no problem, just as long as=20 everyone involved realizes that while the core code itself is BSD, the=20 program as a whole will have some non-BSD code linked to it (i.e=20 Sleepycat/GPL for the db, LGPL for libgedcom, etc). This of course is=20 no problem as long as it stays open source, but it would be an obstacle=20 for someone trying to close-source it (which I'm not sure would be a=20 good thing anyway). > Yeah; maybe we can make extensions possible in a couple of different > ways. Ruby sounds like a definite way to go. Is it fairly widely > used? For my benefit can you give a couple of examples of where it's > being used? Well, for example, it's part of the regular bindings for several GUI=20 toolkits wxWindows (wxRuby), FOX (FxRuby), subversion distributes ruby=20 language bindings, SDL has ruby bindings, it's used as a scripting=20 language in several MUDs (Mooix & others)... Here are some interesting links: http://www.ruby-lang.org (the main site) http://www.rubycentral.com (an online reference and tutorial book) http://rubyforge.org/ (a sourceforge like place just for ruby projects) http://raa.ruby-lang.org/ (sorta like CPAN for ruby...) =2D-=20 Wesley J. Landaker - wj...@ic... OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 |
|
From: Wesley J L. <wj...@ic...> - 2003-08-12 00:17:35
|
On Sunday 10 August 2003 8:20 pm, David M. Brown wrote: > Wesley J Landaker wrote: > > I haven't tried any lately (which is why I suggested that we look > > at the state of things now), but back when I tried them, most > > geneology programs were sorely lacking. > Ok, so my original idea for LAF was to be a PAF clone. This > especially goes for both ends of the software usage (GUI and file > format, the former being most important (as long as we don't get into > trouble)). I wanted a PAF user to sit down and start using LAF from > day one and not even know they were using LAF. Sure, there are going > to be some subtle differences, but as much as is feasibly possible > make it a PAF look-and-feel-alike. That was the first and foremost > feature and all other features, as long as they don't detract from > this first feature, would be considered. > > With that in mind... I think this is a great way to do it. Not only does it mean it's easier=20 for the user, but it actually makes the developers job somewhat easier=20 as there isn't a lot of overhead investment in redesigning GUIs and so=20 forth. I think we agree pretty much here. =3D) > > - Be familiar to PAF users. That is, our GUI should work as much > > like PAF as makes sense. > > Even a little into the "does that really make sense?" realm should be > done. In other words, there may be extra effort invovled (more than > usual) to make it look like PAF so that PAF users are completely > comfortable. I think we agree here. My only concern would be if there was something=20 buggy/broken/lame about PAF we should fix it. I don't mean to change=20 things just for the sake of changing them, though.=20 > > - Be *better* than PAF; be open and extendable. That is, if we > > can do something better than PAF does it, or add new features that > > PAF lacks, we should do it. > > Yes, but only to the extent that we don't take away from the PAF > similarities. I'll admit there are things in PAF that I would have > done differently, but there will be some things that we'll have to > implement that we won't like just to make it familiar to PAF users. Again, I think we agree. What I would have it mind is that all the same=20 PAF functionality and feel would still be there, but we can enhance=20 things in the backend. While there may be some things we want to add to=20 the menus or something, I don't think the GUI would need to be very=20 different to handle things that the current PAF doesn't. For example,=20 we really ought to having full unicode support; the current PAF (last=20 time I looked at it) doesn't support this at all/very well. What if I=20 have an ancestor named =E7=94=B0=E4=B8=AD=E3=81=BE=E3=81=95=E5=AD=90? =3D) > >>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 round-tripping is possible without data loss. However, this > > may (or may not) require some reverse-engineering effort. We might > > want to start off with GEDCOM support, but out file I/O subsystem > > should be pluggable. =3D) > > Exactly. > > I'll start a list on SourceForge of the project goals as soon as I > see a little more feedback on what we think the goals should be.=20 > Your email is a wonderful start (and is probably close to the > finished list) for everyone to comment on. At least we have a few > people now on the list who can comment (more than we had before), but > the number is small enought that I'd hope everyone would comment. Yeah, that would be great if we can sort of "canonize" them on the SF=20 page somewhere. We can always update them as we go along if we need to,=20 but we just want to make sure that we are all trying for something in=20 common in the first place. ;) =2D-=20 Wesley J. Landaker - wj...@ic... OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 |
|
From: David M. B. <da...@da...> - 2003-08-15 15:24:08
|
Wesley J Landaker wrote: [...] >>I'll start a list on SourceForge of the project goals as soon as I >>see a little more feedback on what we think the goals should be. >>Your email is a wonderful start (and is probably close to the >>finished list) for everyone to comment on. At least we have a few >>people now on the list who can comment (more than we had before), but >>the number is small enought that I'd hope everyone would comment. > > > Yeah, that would be great if we can sort of "canonize" them on the SF > page somewhere. We can always update them as we go along if we need to, > but we just want to make sure that we are all trying for something in > common in the first place. ;) I don't remember if I already sent this or not. Since I don't remember it being sent back to me by the list I'm sending it now. :) I started this doc a few days ago. It's at https://sourceforge.net/docman/display_doc.php?docid=18453&group_id=20350 Please let me know anything you think should be changed or added. I definitely want to keep this goals list short, so I don't think much should be added. But if someone comes up with something good, let's get it in there. I also expect we'll come up with other lists of more concrete decisions, but this list is meant to stick to the abstract overall goals. Thanks, David |
|
From: Wesley J L. <wj...@ic...> - 2003-08-17 20:52:25
|
On Friday 15 August 2003 9:19 am, David M. Brown wrote: > I don't remember if I already sent this or not. Since I don't > remember it being sent back to me by the list I'm sending it now. :) > > I started this doc a few days ago. It's at > https://sourceforge.net/docman/display_doc.php?docid=3D18453&group_id=3D2 >0350 > > Please let me know anything you think should be changed or added. I > definitely want to keep this goals list short, so I don't think much > should be added. But if someone comes up with something good, let's > get it in there. I also expect we'll come up with other lists of > more concrete decisions, but this list is meant to stick to the > abstract overall goals. I think it looks pretty good so far. =3D) BTW, I haven't done much concrete with laf this last week, but I've been=20 spending a little time becoming re-familiar with PAF, since I haven't=20 used it in a while. Anyone else been doing anything or have any thoughts on the program,=20 tools, goals, anything? =3D) I think the hardest thing to do sometimes is=20 to get projects rolling, 'cause were all busy, but let's keep at it. ;) =2D-=20 Wesley J. Landaker - wj...@ic... OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 |
|
From: David M. B. <da...@da...> - 2003-08-10 08:29:50
|
Hey all. I'm glad someone poked my memory about this project. I more or less had forgotten about it. :/ I'm also glad to see that some people are ready to go on it. Unfortunately I won't be able to do a whole lot since I'm switching jobs in about a week or so and will be busy getting up to speed there. But I have no problem at all putting forth what effort I can, especially when I get a feel for this new job. So, I think it would be helpful to get an idea of who has what skills. This seems like it is already coming out in the emails so far. It also helps to know who wants to do what. I don't mind doing project management type stuff. But in order to do that I need lots of feedback initially on who wants to do what. I'll go out and start poking the project again on SF. Also, keep the design ideas flowing. One last thing. I know a couple of people who work for the LDS church software development department, but I'm not sure if they work on PAF or not. They may be able to get me some information on PAF's native file format, though. Heh, I once wrote to them a while back about doing this project and getting what help we could from them, and they were absolutely NOT interested. Maybe things will have changed by now. Anyway, here we go! Thanks, David Samuel G. Shirley wrote: > Hello Everyone, > > I had joined this nailing list a LONG time ago and even forgot about the > project until somebody starting email again. :-) > > I'm glad that there is interest in working on this project again. > > >>>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. > > >>>>One thing we might want to do is scope out other linux-based >>>>geneology programs out there and make sure there isn't already >>>>something that 1) already does everything we need and we just don't >>>>realize it, or 2) could be forked to be PAF-compatible. I'd rather >>>>not duplicate work unless it's necessary. =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. > > >>Question: how important is it to you to have PAF file-format=20 >>compatibility? GEDCOM is certainly no problem, but the PAF database=20 >>files themselves have changed format in every version of PAF and I=20 >>don't know if they are documented anywhere... certainly we could=20 >>reverse-engineer them if it's worth it to.=20 > > > 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. > > >>GUI: Of course, we need a GUI. This would be layered on top of the core,=20 >>and thus we avoid mixing GUI and core logic. > > > Again....PAF cloning would be nice. > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > LAF-devel mailing list > LAF...@li... > https://lists.sourceforge.net/lists/listinfo/laf-devel |
|
From: David M. B. <da...@da...> - 2003-08-10 08:35:47
|
BTW, Samuel, Robert, and Wesley, if you are interested in being added to the project as developers, let me know what your SourceForge username is. You all seem to have good ideas, and I have no problem adding you to the project. Thanks, David Samuel G. Shirley wrote: > Hello Everyone, > > I had joined this nailing list a LONG time ago and even forgot about the > project until somebody starting email again. :-) > > I'm glad that there is interest in working on this project again. > > >>>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. > > >>>>One thing we might want to do is scope out other linux-based >>>>geneology programs out there and make sure there isn't already >>>>something that 1) already does everything we need and we just don't >>>>realize it, or 2) could be forked to be PAF-compatible. I'd rather >>>>not duplicate work unless it's necessary. =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. > > >>Question: how important is it to you to have PAF file-format=20 >>compatibility? GEDCOM is certainly no problem, but the PAF database=20 >>files themselves have changed format in every version of PAF and I=20 >>don't know if they are documented anywhere... certainly we could=20 >>reverse-engineer them if it's worth it to.=20 > > > 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. > > >>GUI: Of course, we need a GUI. This would be layered on top of the core,=20 >>and thus we avoid mixing GUI and core logic. > > > Again....PAF cloning would be nice. > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > LAF-devel mailing list > LAF...@li... > https://lists.sourceforge.net/lists/listinfo/laf-devel |
Thanks for helping keep SourceForge clean.
X