laf-devel — Linux Ancestral File Developer Discussions

[LAF-devel] Stuck LAF Project

[David M. B. <da...@da...>]

No matter how much time I try to (or actually do) devote to this, it 
doesn't seem that it is enough.  I get work done locally, but then never 
have the chance to update sf.net.  Or I have ideas that never make it 
from my brain to the keyboard.

So, I'm cancelling this project as far as I have anything to do with it. 
  If someone else would like to take it and run with it, I'd be more 
than happy to give it to you.  Just let me know ASAP.  Otherwise I'll 
delete the project on May 10.  If that's the course of action taken, I'd 
recommend everyone throw their efforts behind gnuology...

Thanks to everyone who had great ideas and wanted to see this thing go. 
  Sorry I haven't had more time and energy to spend on this.

David

Re: [LAF-devel] Re: LAF-devel digest, Vol 1 #14 - 2 msgs

[David M. B. <da...@da...>]

I sent an email yesterday (two days ago?) about some general things... 
I finally have a linux box at home that is worthy of software 
development.  (Most of my linux/BSD boxes are old pentium 166 types for 
servers, etc.)  But I think I'll be pulling back and really starting 
this project more or less on my own for now.  As soon as I get a good 
foundation to work from I'll start looking for people to flesh things out.

Of course, the first thing I'm going to do is see if I can't get PAF 
working under wine.  I know a lot of people have tried this, but with 
the latest wine and PAF I think there just might be hope.  I know one of 
the wine developers fairly well; I'll probably solicit his help.  After 
all, if PAF can run under wine, then there's no reason to start LAF.

With that being said, I'll probably "reset" the project on sourceforge 
to give it a clean start.  If anyone really wants to be a developer of 
the project, please let me know what you have to offer.  We're starting 
from scratch here, so you'll need to be added again.  At first though 
there probably won't be a whole lot of need for developers on the 
project (as far as the sourceforge definition of "developer" goes, e.g., 
release techs, project managers, etc.).  So I probably won't be adding 
anyone for a while unless someone gives me a really good reason why I 
should.

I do appreciate all those who have given me ideas both on this list over 
the last couple of years as well as in private email.  I think there are 
some very smart people here and I hope you all stick around on the list. 
  This will be the third(!!!) time I've made a run at this project, and, 
as they say, the third time's the charm.

Thanks,
David


Wesley J Landaker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wednesday 11 February 2004 7:50 am, Samuel G. Shirley wrote:
> 
>>It's been a LONG time since I've poosted here. :-)
> 
> 
> A long time since anyone has, really. =)
> 
> 
>>I wanted to say that I agree with the decision to use Qt.
>>Multi-platform is a good thing. Of course, GTK with work well too.
>>
>>As far as the name goes, I am a fan of the Open thing. OpenBeOS,
>>OpenThis, OpenThat. How about OpenPAF or Open Ancestry File?
> 
> 
> That would probably work too. At this point, I think the biggest danger 
> is that we'll never have anything working more than that the name will 
> be wrong. ;)
> 
> Unfortunately, I've got many other projects that I'm actively working 
> on, and this project has kind of stagnated. I want to see it (or 
> something like it) succeed, but as I stated a while back, I'm not going 
> to be able to drive this project forward at this point.
> 
> OTOH, if someone steps forward to get things rolling, I will be happy to 
> contribute technically. =)
> 
> - -- 
> Wesley J. Landaker <wj...@ic...>
> OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFALi9m8KmKTEzW49IRAqL5AJ44jnG1wodj/H+uFZLh7/igbRdaIwCfVeA9
> 0lvT+hChJT3Bkvy6mdSAvic=
> =gHz5
> -----END PGP SIGNATURE-----
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id56&alloc_id438&op?k
> _______________________________________________
> LAF-devel mailing list
> LAF...@li...
> https://lists.sourceforge.net/lists/listinfo/laf-devel
> 

Re: [LAF-devel] Re: LAF-devel digest, Vol 1 #14 - 2 msgs

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 11 February 2004 7:50 am, Samuel G. Shirley wrote:
> It's been a LONG time since I've poosted here. :-)

A long time since anyone has, really. =3D)

> I wanted to say that I agree with the decision to use Qt.
> Multi-platform is a good thing. Of course, GTK with work well too.
>
> As far as the name goes, I am a fan of the Open thing. OpenBeOS,
> OpenThis, OpenThat. How about OpenPAF or Open Ancestry File?

That would probably work too. At this point, I think the biggest danger=20
is that we'll never have anything working more than that the name will=20
be wrong. ;)

Unfortunately, I've got many other projects that I'm actively working=20
on, and this project has kind of stagnated. I want to see it (or=20
something like it) succeed, but as I stated a while back, I'm not going=20
to be able to drive this project forward at this point.

OTOH, if someone steps forward to get things rolling, I will be happy to=20
contribute technically. =3D)

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

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFALi9m8KmKTEzW49IRAqL5AJ44jnG1wodj/H+uFZLh7/igbRdaIwCfVeA9
0lvT+hChJT3Bkvy6mdSAvic=3D
=3DgHz5
=2D----END PGP SIGNATURE-----

[LAF-devel] Re: LAF-devel digest, Vol 1 #14 - 2 msgs

[Samuel G. S. <ssh...@cs...>]

It's been a LONG time since I've poosted here. :-)

I wanted to say that I agree with the decision to use Qt. Multi-platform
is a good thing. Of course, GTK with work well too.

As far as the name goes, I am a fan of the Open thing. OpenBeOS, OpenThis,
OpenThat. How about OpenPAF or Open Ancestry File?


On Sun, 24 Aug 2003 laf...@li... wrote:

> Send LAF-devel mailing list submissions to
> 	laf...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.sourceforge.net/lists/listinfo/laf-devel
> or, via email, send a message with subject or body 'help' to
> 	laf...@li...
>
> You can reach the person managing the list at
> 	laf...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of LAF-devel digest..."
>
>
> Today's Topics:
>
>    1. PAF GUI + screenshots (Wesley J Landaker)
>    2. project name (Wesley J Landaker)
>
> --__--__--
>
> Message: 1
> From: Wesley J Landaker <wj...@ic...>
> To: laf...@li...
> Date: Sun, 24 Aug 2003 15:53:40 -0600
> Subject: [LAF-devel] PAF GUI + screenshots
>
>
> --Boundary-02=_pPTS/5JbImWcSZS
> Content-Type: text/plain;
>   charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> Content-Description: signed data
> Content-Disposition: inline
>
> Hey folks,
>
> Since one of our goals is to emulate the PAF GUI, unless there is=20
> someone else who is itching to work on this, I think I'm going to start=20
> creating all the forms and dialogs into which the backend can be=20
> plugged. I'm going to be using Qt... any objections? =3D)
>
> Also, I'm going to take some screenshots of PAF (actually, my wife=20
> volunteered to do this) so we have them for reference.
>
> =2D-=20
> Wesley J. Landaker - wj...@ic...
> OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
>
>
>
>
>
>
> --Boundary-02=_pPTS/5JbImWcSZS
> Content-Type: application/pgp-signature
> Content-Description: signature
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQA/STPp8KmKTEzW49IRAt89AKCI6w01kgDrYcU651/HGYdd+Tu73gCcCAtf
> GiuMdFrl8CHJCVqk9vrihSo=
> =oBH4
> -----END PGP SIGNATURE-----
>
> --Boundary-02=_pPTS/5JbImWcSZS--
>
>
>
> --__--__--
>
> Message: 2
> From: Wesley J Landaker <wj...@ic...>
> To: laf...@li...
> Date: Sun, 24 Aug 2003 15:57:46 -0600
> Subject: [LAF-devel] project name
>
>
> --Boundary-02=_eTTS/qA311DyCCU
> Content-Type: text/plain;
>   charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> Content-Description: signed data
> Content-Disposition: inline
>
> Hey folks,
>
> Here is a thought I had while working on some dialogs: the project name=20
> right now is LAF, for "Linux Ancestral File". Linux is our main target,=20
> after all.
>
> However, with the toolset we are using, LAF will be able to run on just=20
> about any platform, including Linux, NetBSD, FreeBSD, and even MacOS=20
> and Windows.
>
> What if we changed the name ever so slightly to FAF (my wife's=20
> suggestion): "Free Ancestral File". Pretty cool, huh? Well, I thought=20
> so. ;) Let's hear what you guys think.
>
> =2D-=20
> Wesley J. Landaker - wj...@ic...
> OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
>
>
>
>
>
>
> --Boundary-02=_eTTS/qA311DyCCU
> Content-Type: application/pgp-signature
> Content-Description: signature
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQA/STTe8KmKTEzW49IRAs1jAJ9o/UYyfBn89YkwAX5zulWipj4ZCACeM12x
> i3zM3dFWqmZNLqN5UOQXzi0=
> =H1DB
> -----END PGP SIGNATURE-----
>
> --Boundary-02=_eTTS/qA311DyCCU--
>
>
>
>
> --__--__--
>
> _______________________________________________
> LAF-devel mailing list
> LAF...@li...
> https://lists.sourceforge.net/lists/listinfo/laf-devel
>
>
> End of LAF-devel Digest
>
>

=============================================================================
Samuel Shirley <ssh...@cs...>
Warwick, Rhode Island
02889
USA
+401.419.6350

		Quidquid latine dictum sit, altum videtur.
		Whatever is said in Latin sounds profound.

=============================================================================

Re: [LAF-devel] I'm still around

[David M. B. <da...@da...>]

Great advice.  Also, I have some project tasks laid out for this first 
phase (and some that probably leak into later development phases), I 
just need to get it all into sourceforge.  Hopefully I'll have time for 
that within the next week.

Thanks!

David

Wesley J Landaker wrote:
> Hi folks!
> 
> Just wanted to say that I'm still around and have been poking around on 
> this a little bit. I've been out of town the last few weekends, so I 
> haven't had time to work too much.
> 
> Anyway, if anyone else is itching to work on anything, I'd encourage you 
> to a piece of the program that sounds interesting and start planning 
> out how to implement it or coding up some prototype code.
> 

[LAF-devel] I'm still around

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

Hi folks!

Just wanted to say that I'm still around and have been poking around on=20
this a little bit. I've been out of town the last few weekends, so I=20
haven't had time to work too much.

Anyway, if anyone else is itching to work on anything, I'd encourage you=20
to a piece of the program that sounds interesting and start planning=20
out how to implement it or coding up some prototype code.

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

Re: [LAF-devel] PAF GUI + screenshots

[David M. B. <da...@da...>]

I agree with the PAF being free thing.  Sure I understand you mean the 
GNU kind of free, but many might not catch that.  I have a feeling 
people will understand that LAF can also run on other platforms.  Most 
folks already have the mindset that Linux apps already or can with some 
tweaking run on other Unixes.  Hmm...  I'm just so stuck on Linux 
Ancestral File already.  And I wanted the name to be close to PAF since 
it is meant to act like PAF.

If OAF didn't already have something of a negative connotation ("that 
guy is such a big oaf!") I'd probably go for that.  Time to think...

David

ro...@le... wrote:
> I've been taking tons of screenshots for my documentation on what PAF does 
> and how it works.  
> 
> Oh also, I'm not so sure about naming it Free Ancestoral File.  I mean PAF 
> is already Free of cost and naming it FAF may imply it is not.  How bout 
> OAF?  Or Open Ancestoral File?  Or how bout AAF, (Alternate Ancestoral 
> File), or SOAF - Some other ancestoral file?  Or QAF QT ancestoral file.  
> Or NWAF - Not Windows Ancestoral File.  Or APAF another personal 
> ancestoral file.
> 
> Regards,
> Robert.
> 
> 
> 
>>Hey folks,
>>
>>Since one of our goals is to emulate the PAF GUI, unless there is 
>>someone else who is itching to work on this, I think I'm going to start 
>>creating all the forms and dialogs into which the backend can be 
>>plugged. I'm going to be using Qt... any objections? =)
>>
>>Also, I'm going to take some screenshots of PAF (actually, my wife 
>>volunteered to do this) so we have them for reference.
>>
>>-- 
>>Wesley J. Landaker - wj...@ic...
>>OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
>>
>>
>>
>>
> 
> 
> 
> 
> ---------------------------------------------
> This message was sent using Endymion MailMan.
> http://www.endymion.com/products/mailman/
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> LAF-devel mailing list
> LAF...@li...
> https://lists.sourceforge.net/lists/listinfo/laf-devel

Re: [LAF-devel] PAF GUI + screenshots

[<ro...@le...>]

I've been taking tons of screenshots for my documentation on what PAF does 
and how it works.  

Oh also, I'm not so sure about naming it Free Ancestoral File.  I mean PAF 
is already Free of cost and naming it FAF may imply it is not.  How bout 
OAF?  Or Open Ancestoral File?  Or how bout AAF, (Alternate Ancestoral 
File), or SOAF - Some other ancestoral file?  Or QAF QT ancestoral file.  
Or NWAF - Not Windows Ancestoral File.  Or APAF another personal 
ancestoral file.

Regards,
Robert.


> Hey folks,
> 
> Since one of our goals is to emulate the PAF GUI, unless there is 
> someone else who is itching to work on this, I think I'm going to start 
> creating all the forms and dialogs into which the backend can be 
> plugged. I'm going to be using Qt... any objections? =)
> 
> Also, I'm going to take some screenshots of PAF (actually, my wife 
> volunteered to do this) so we have them for reference.
> 
> -- 
> Wesley J. Landaker - wj...@ic...
> OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2
> 
> 
> 
> 



---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/

[LAF-devel] PAF GUI + screenshots

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

Hey folks,

Since one of our goals is to emulate the PAF GUI, unless there is=20
someone else who is itching to work on this, I think I'm going to start=20
creating all the forms and dialogs into which the backend can be=20
plugged. I'm going to be using Qt... any objections? =3D)

Also, I'm going to take some screenshots of PAF (actually, my wife=20
volunteered to do this) so we have them for reference.

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

[LAF-devel] project name

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

Hey folks,

Here is a thought I had while working on some dialogs: the project name=20
right now is LAF, for "Linux Ancestral File". Linux is our main target,=20
after all.

However, with the toolset we are using, LAF will be able to run on just=20
about any platform, including Linux, NetBSD, FreeBSD, and even MacOS=20
and Windows.

What if we changed the name ever so slightly to FAF (my wife's=20
suggestion): "Free Ancestral File". Pretty cool, huh? Well, I thought=20
so. ;) Let's hear what you guys think.

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

[LAF-devel] project name

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

Hey folks,

Here is a thought I had while working on some dialogs: the project name=20
right now is LAF, for "Linux Ancestral File". Linux is our main target,=20
after all.

However, with the toolset we are using, LAF will be able to run on just=20
about any platform, including Linux, NetBSD, FreeBSD, and even MacOS=20
and Windows.

What if we changed the name ever so slightly to FAF (my wife's=20
suggestion): "Free Ancestral File". Pretty cool, huh? Well, I thought=20
so. ;) Let's hear what you guys think.

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

[LAF-devel] PAF GUI + screenshots

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

Hey folks,

Since one of our goals is to emulate the PAF GUI, unless there is=20
someone else who is itching to work on this, I think I'm going to start=20
creating all the forms and dialogs into which the backend can be=20
plugged. I'm going to be using Qt... any objections? =3D)

Also, I'm going to take some screenshots of PAF (actually, my wife=20
volunteered to do this) so we have them for reference.

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

Re: [LAF-devel] Re: Design

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

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

Re: [LAF-devel] Re: Design

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

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

Re: [LAF-devel] Forums or Lists?

[David M. B. <da...@da...>]

ro...@le... wrote:

> I like e-mails for the reasons you have given.  However, between the two 
> I'ld take forums if the forum is well designed do to the organizational 
> quality of forums. Fact that between school, work, and visiting family, I 
> don't have one computer where my e-mails rest.  
> 
> I do like things organized into threads, where I can look at what 
> interests me and not waste my time on things that don't concern me but get 
> sent out to the list anyway.  
> 
> Browsing around today I found this:
> 
> "If you monitor forums, you will be sent new posts in the form of an 
> email, with a link to the new message.
> 
> You can monitor forums by clicking "Monitor Forum" in any given discussion 
> forum."
> 
> Sounds like the best of both worlds to me.  Any comments?

That's ALMOST perfect.  I'll have to see if there's a way to have it 
send the actual contents of what is in the forum.  That would be best.

Here's my latest thought:

As far as discussions on design, features, etc., I think email is 
probably better.  At least we should make sure that the subject matter 
for email lists is very specifically defined.  In other words, laf-devel 
would probably go away, and we'd create lists for things like 
laf-ui-devel, or laf-db-devel, for specific topics.

Then, forums can be more for end-user discussion, support, etc.  In 
other words, we'd keep devel discussions to specific email lists, but 
general discussions in forums.

Or am I making it too complex?

My thinking is that email lists allow development to move ahead more 
quickly since everyone sees things as they come.  Forums, on the other 
hand, are better for keeping inboxes clean, but slow things down a bit 
since I have to go an extra step and check the forum.  Even with the 
link emailed to me I'm this way as I have to click it.  I know, how lazy 
can I get?  Well, it's just one more step where the potential to say, 
"I'll check it later..." is far too great. :)

So, if the development turns out to move ahead quickly, email lists are 
better.  If we take our time (which is fine, let's do what it takes but 
keep people happy), then forums are ok.

One more idea:  Maybe we start with forums for now, and as we deem 
necessary split out email groups like I mentioned (laf-db-devel, etc.)?

I know it seems like I'm making a big deal out of something that 
shouldn't be a big deal.  But, if we don't set up communication to work 
well from the start, we'll have difficulty getting this thing off the 
ground.  Good communication is the key to a good 
marriage^H^H^H^H^H^H^H^H project. :)

Thoughts?

David

Re: [LAF-devel] Forums or Lists?

[<ro...@le...>]

I like e-mails for the reasons you have given.  However, between the two 
I'ld take forums if the forum is well designed do to the organizational 
quality of forums. Fact that between school, work, and visiting family, I 
don't have one computer where my e-mails rest.  

I do like things organized into threads, where I can look at what 
interests me and not waste my time on things that don't concern me but get 
sent out to the list anyway.  

Browsing around today I found this:

"If you monitor forums, you will be sent new posts in the form of an 
email, with a link to the new message.

You can monitor forums by clicking "Monitor Forum" in any given discussion 
forum."

Sounds like the best of both worlds to me.  Any comments?

Regards,
Robert


> Just a quick question...  Which do people like better?  Email lists or 
> forums?
> 
> I like lists for the fact that I'm more or less "forced" into reading 
> things more frequently.  On the other hand, forums provide a more 
> friendly, read-as-you-like feel.  Maybe there's a way to configure 
> sourceforge's forums to email posted messages?  I haven't looked into 
> that, and their site is down for maintenance right now.  If that's the 
> case, I'd vote for forums.
> 
> Thoughts?
> 
> Thanks,
> David
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> 


---------------------------------------------
This message was sent using Endymion MailMan.
http://www.endymion.com/products/mailman/

Re: [LAF-devel] Re: Design

[David M. B. <da...@da...>]

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

Re: [LAF-devel] Re: Design

[David M. B. <da...@da...>]

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


> 

Re: [LAF-devel] Re: Design

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

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

Re: [LAF-devel] Re: Design

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

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

Re: [LAF-devel] Forums or Lists?

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

On Sunday 10 August 2003 8:27 pm, David M. Brown wrote:
> Just a quick question...  Which do people like better?  Email lists
> or forums?
>
> I like lists for the fact that I'm more or less "forced" into reading
> things more frequently.  On the other hand, forums provide a more
> friendly, read-as-you-like feel.  Maybe there's a way to configure
> sourceforge's forums to email posted messages?  I haven't looked into
> that, and their site is down for maintenance right now.  If that's
> the case, I'd vote for forums.

I can work either way, but it's much faster and easier for me to use=20
e-mail than forums, and I'm likely to check my e-mail a lot more often.=20
;)

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

[LAF-devel] Re: LAF-devel digest, Vol 1 #9 - 1 msg

[Samuel G. S. <ssh...@cs...>]

> I like lists for the fact that I'm more or less "forced" into reading
> things more frequently.  On the other hand, forums provide a more
> friendly, read-as-you-like feel.  Maybe there's a way to configure
> sourceforge's forums to email posted messages?  I haven't looked into
> that, and their site is down for maintenance right now.  If that's the
> case, I'd vote for forums.

I, myself, am more into forums. BTW, my sourceforge username is sshirley
if someone wants to add me. :-)

[LAF-devel] Forums or Lists?

[David M. B. <da...@da...>]

Just a quick question...  Which do people like better?  Email lists or 
forums?

I like lists for the fact that I'm more or less "forced" into reading 
things more frequently.  On the other hand, forums provide a more 
friendly, read-as-you-like feel.  Maybe there's a way to configure 
sourceforge's forums to email posted messages?  I haven't looked into 
that, and their site is down for maintenance right now.  If that's the 
case, I'd vote for forums.

Thoughts?

Thanks,
David

Re: [LAF-devel] Re: Design

[David M. B. <da...@da...>]

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. ;)
> 

Re: [LAF-devel] Re: Design

[David M. B. <da...@da...>]

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