Richard Taylor wrote:
> 
> 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.
> 

If I get a chance later this week (my new server is almost done, but the
holidays are fast approaching...) I'll see about putting up a snapshot
tarball.

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

I like this data model.  By providing the means for the user to store
the location of additional information, where it is available, but still
allowing the the user to enter as much information as desired in the
local database, we gain the best of both worlds.  There are a couple of
ways we could implement this in the current schema...

   - Add a table to hold URL references.  This new table could
     consist of three fields: PersonID, URL, Notes.

   - Define a special Event Type called URL with which to store
     this information.  With this Event Type, the date would be
     stored as 00/00/0000 and the program would not allow the 
     user to enter a date for this event.

I'm partial to the second of these options, because on some of my lines,
its likely that there would be several places on the internet that would
have additional information (I'm currently researching a branch that
connects to Oliver Wendell Holmes).  If the information is stored as an
event with a zero date, it would sort to the top of the Event list, and
be instantly seen as a reference to additional information, regardless
of how much additional data I store on my own.

The only concern with this strategy is that we have no control over how
the additional information is presented on the internet.  Do we just
display the page in a browser for the user to peruse or try to display
the information in Genes' native format?  Naturally, the browser would
be easier to code, but if the database is in a standard format already
(i.e. GEDCOM)...

Whatever we decide for this, we need to get Genes to a version where it
is usable first, then we can look at displaying foreign data in this
way.

This brings up another problem that we've been trying to tackle at work,
that of feature creep.  During development on a few projects, we've
found that our users keep asking us to add "just this one little thing"
to the programs we develop.  The problem this causes is that the simple
two-day report suddenly becomes much larger in scope and is delivered
much later (on the order of months) than originally anticipated.  What
we're doing to combat this is to create a Project Requirements Document
(PRD) for every project that we work on.

The PRD spells out precisely what tools will be used, what features are
required and what user interface elements will be added and/or updated
for the project.  It also outlines the proposed implementation schedule,
breaking the project down into installation phases, listing exactly
which requirements will be implemented for each phase.  I should be able
to get a basic .tex file on the site relatively soon (as well as one
filled in for Genes itself) that we can start using as a guide...

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

This type of integration is something that I need to research more. 
Maybe I'm just jaded by the integration that I've seen from Micros~1,
but I've always favored little programs that do specific tasks
independently of other apps.  However, more on a similar scripting vein
later...

[snip: screen abstraction patterns]
> 
> 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.
> 

I had originally thought of using Qt because I had the documentation for
it and I had heard rumors at the time about a compact version for
handheld devices (which has since become Qt Embedded).  The Toucan book
presented the library in a way that I could easily comprehend what was
going on in a program that used it.

The GTK screenshots were produced by a program called Glade.  While this
app allows the user to create screens quickly and produces pretty handy
fill-in-the-blank code, I don't like the tight-coupling that this code
would produce.  I would much rather build in an abstraction layer so it
could be run with curses or any windowing library.  I'll check out the
XEmacs code to see what we can steal from it...

> 
> I will have a go at some Qt dialogs if you like.
> 

That would be cool, since it's always helpful to see gui proposals.

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

This would be even cooler.  It would be a perfect enhancement for a
report writer, in addition to the standard report types that we will
most assuredly need (Pedigree, Ahnentafel [sp?], Journal, etc.).

--
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

Reply via email to