On Tuesday 12 December 2000 21:38, you wrote:
> Richard Taylor wrote:
>[snip: distributed database stuff]
>
> 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.
I think there are two subtly different aspects to this:
- firstly, where there is information about someone we are interested in
and we just want to link to that information. Why not put the URL in
as a repository and enter a source record against an attribute on the
person. It seams to me that a Web site is no different to a library it is
just another repository. We could even just be clever about parsing
repository names and turn them into links if they look like a URL. Then
not change would be nedded to the DB at all.
- secondly, where we actually want to link two databased together accross
the Internet. This would enable queries to run across many families if
they happened to overlap. Web page format is not sufficient for this to
work. The return from accross the web would have to be in a machine
readable form (something like XML) and the access to the remote site
would need to be a remote procesure call (something like SOAP). When we
are working on our own database no Internet connection happens but when
we want to do a query that could take in information from another persons
database the Internet would be used automatically. There is of course lots
of issues about letting user veto this, given appropriate user feedback
etc. but that is all User Interface stuff.
> 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)...
>
In the first case you just display the linked page. In the second you expect
formated data in return for you query.
> 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.
>
I agree. None of this would have a major affect on the DB structure. Better
to have a basic working system and then evolve it. As long as the DB
interface is clean.
> 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 am not too sure about this in a volunteer project. In my experience people
will work on the bit of the project that interests them. Feature creep is a
problem when those doing the code are not those specifying the requirement.
Have a plan sure. A simple list of major tasks would be OK at this point.
People can be put themselves forward for leading on those tasks (the smaller
the task the better). There is already something of that emerging:
- DB structure
- DB interface layer
- Object Model Design and implementation
- Support classes (Date etc.)
- UI design
- Report writing design
Targets are a tricky thing for free software developers. I don't know about
you but I can only work on this type of stuff in the cracks between the rest
of life (currently by other half is at the staff Xmas party!).
I guess the upside is that we have all the time in the world to do it. No one
is going to pull the plug on funding :-)
> > 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 have had a peek at how XEmacs does it and it is horible. A better model is
abiword. It appears there is three basic approaches to the problem:
- write your own widget set and framework and make that portable accross all
platforms. This is the Netscape (Mozilla) ways.
- write an abstraction layer for the framework and use the native widgets
where possible. This the abiword way. It does mean that you don't
integrate well into the native environments well though.
- write the data model and as much of the raw processing in a GUI
independent way and then independantly write the GUI for each
target platform.
Personnally I prefer that third option. I like my applications to integrate
tightly into the GUI I am using. I would like Bonobo support in GNOME, KParts
support in KDE and OLE support in MS Windows. Sometimes this is a pain
because the majority of the application is the GUI but for Genes I am not
sure this is the case. I think the most work is in the Object Model, report
engine and the database code. Most of the GUI is just dialogs and
presentation.
Ah well time to pick of the other half from the party.
It is late here so forgive me if I have rambled a bit.
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
