Hi everyone,
I am a newbie to the list so bear with me if I cover old ground.
I have been lurking for a couple of days now and I have read the dbschema and
the archived of the list.
It would be nice if someone could provide a snapshot of the cvs via ftp or
http because I can not get cvs through my company firewall.
I have made further comments inline below.
I hope to be able to help out if my limited spare time allows.
On Tuesday 12 December 2000 15:39, you wrote:
> Martin Cameron wrote:
> > Hi David
> >
> > The outline that you give - of distributed data - is a great one. I have
> > been thinking along the same lines for quite a while. However, the medium
> > that I would use would be one more specifically designed for the task - a
> > Mysql database, the program written in PHP and Apache acting as the
> > go-between.
> >
> > Over Christmas, I have promised myself to design the tables for the
> > database. Because I don't really understand all of the interactivity of
> > the various relationships yet, that the biggest hurdle. Once I've come to
> > terms with that, then we're away.
>
> A couple of other thoughts from me....
>
> First, a welcome to those new to the project. Any help is greatly
> appreciated.
>
> When I started this project, I was hoping to build a program that could
> be used at least on my desktop and laptop boxen. This does involve a
> bit of synchronization between two databases, as my desktop is not on a
> dedicated connection and I want to take my laptop to the library to do
> some research. I don't want to connect to the internet just to perform
> this synchronization (I object very strongly to programs that require an
> internet connection when they should work perfectly well as standalone
> applications; check out my editorial on this in the OS Opinion
> archives).
>
I agree entirely with your sentiments about unneeded dialup.
I have been thinking about this 'distrubted database' stuff. I was wondering
about linkage between databases rather than distribution of a single
database. So that, if your linage interlinks somewhere with one that is being
developed by someone else you could simply link to it rather than take a copy
and merge it with your own. Clearly when you wanted to look at an entry in
the linked linage you would need to dial but that may be preferable to having
multiple updates and inconsistent (or repeated) entries.
I have been thinking about how to implement this (I have not worked this out
fully yet so bear with me). We could have a table of sites (URLs) that point
to databases including 'localhost' and then references to indivduals would be
compound (id,host) if the host was not 'localhost' a web based lookup could
be performed. We would need to define a web based API (SOAP maybe) that could
be used to retrieve lists of records given a search criteria and individual
records given a 'id'. This lookup could be transparent to any code calling
the object model. It would of course require people to put thier databases
online, but many already to through HTML conversion from GEDCOM. It may even
be possible to transport the references through GEDCOM by using @<url>@ where
ids usually appear but I don't know what other programmes would make of such
entries.
> We've got some basic classes started in C++ in the CVS tree already, and
> I'd rather not dump that entirely for a different language. Since I
> program in C++ at work, and I know what can be done with it, I started
> designing with this in mind.
>
I think you should continue with the C++ line as this can be interfaced with
any of the major scripting environments as long as it remains independant of
any GUI framework (as you intend). Indeed this is how I would see an
implementation of a SOAP based interface. By interfacing into something like
Python it would not be too difficult to proved a SOAP API through Zope
(www.zope.org) for example. But it could equally well be done through perl
(apache, cgi) or PHP ( apache, cgi) (although I do not know much about thier
C++ integration approach).
> On the database drivers, I was hoping to use the Berkeley DB
> (http://www.sleepycat.com) for a couple of reasons - its small size and
> the ability to store variable length records. While a smaller program
> footprint should be a goal of any software project, I don't remember how
> many times I've needed to store something in a database field that is
> just a couple of characters longer than the field length. Plus, with
> the type of data that we are going to store, especially when you
> consider how many extra notes that we need to keep, this would be
> unacceptable. With a variable-sized field, this restriction is
> removed. My goal is to build a database access layer that will be able
> to access records in either Berkeley DB or GEDCOM. This layer would be
> built in such a way as to simplify the creation of other database access
> classes for other database formats to simplify the database import
> process. This can be done, but it has to be done right the first time.
>
Again I think this is a very laudable approach. I would like to see a
Postgres back end (it does support variable length fields) but, as you say,
if the architecture is right this could be added later. It would enable
multiple access to the database (e.g. from a web server application and a GUI
application). I think you are right to go for a simple lightweight DB first
off. It is always best to scratch your own itch first.
> For the user interface, there are a few considerations... Looking at my
> own equipment, I've got a desktop box at home running Caldera with KDE
> as my default desktop; my laptop has a _much_ smaller drive (200
> Megabytes; yeah, it's older, but it's what I've got), that boots with
> Tomsrtbt, and leaves the user at the command line. Like the database
> access layer, we need to build in a screen functionality layer that will
> enable the user to plugin modules for whatever screen library is in use,
> be it curses, Qt, Motif or whatever. The "Gang Of Four" patterns book
> "Design Patterns: Elements of Reusable Object-Oriented Software"
> (http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201633612&vm=)
> has a discussion on how to do this.
>
I am very glad to hear this. I was initially attracted to this effort because
you talked about Qt in some of the documentation, then I noticed the Gnome
screenshots and thought you had changed your mind. I have nothing at all
against Gnome (in fact I like it very much) I just happen to use KDE. I also
like the Qt way of doing things.
I will go and read the design pattern that you mention.
I wonder whether XEmacs has anything to teach us about decoupling widget sets
from code. It supports curses, athena and others. Just an idle thought.
> Finally, we have a database schema already that I posted in April. It
> is online at [http://genes.sourceforge.net/dbschema.html]. There was
> some discussion about it on the mailing list after I posted it, but it
> was more or less accepted as feasible.
>
> Now, what needs to be done?
> We need to build the database access and screen functionality layers so
> we can get cracking.
>
I will have a go at some Qt dialogs if you like.
> Why hasn't it been done yet?
> A lack of time and experience on my part in beginning a project like
> this from scratch. I was hoping to have a prototype over the summer but
> got caught up in my honeydo list ("honey, do this for me...") and a
> complete home LAN rebuild after a couple systems died. I've got some
> small updates to the GenDate class code already in CVS to upload, and it
> will get there as soon as I get my home connection working reliably
> again (we'll probably end up changing ISPs to top it all off). Like
> Linus, I would rather have it done right the first time and not set
> marketing deadlines (which would just be missed anyway).
>
As I said at the top, I can't do CVS through my corporate firewall. I would
like to look at the code to date if you would could either mail be an archive
of make a snapshot available.
> Now, I have a question for the list...
> Are there any listers who are experienced in designing and building the
> two abstraction layers that I've described above?
>
I have written DB driven web applications, MS Windows Applications that use
DBs and a number of other types of programes but I have never attempted the
level of decoupling that you are going for.
One final thought. I have been looking into using embedded scripting
languages as a means of adding flexibility to an application. Embedding a
python interpreter into application of this type does not look too difficult
(especially if you mantain the seperation of concerns that you want). This
would give you a scripting language for writing reports etc. for little
effort.
Hope this is note too much of a ramble. Once I get a moment I will look at
what changes would be needed to the database schema to support remote
database lookup.
Keeps up the good work.
Richard
> --
> Sean Lamb --- [EMAIL PROTECTED] Software Engineer
> while( ) { s/$badcode/$goodcode/g; }
> "A day without laughter is a day wasted." -- Groucho Marx
> _______________________________________________
> Genes-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/mailman/listinfo/genes-devel
_______________________________________________
Genes-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/genes-devel
