[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [help-GIFT] A GIFT roadmap

From: Henning Müller
Subject: Re: [help-GIFT] A GIFT roadmap
Date: Wed, 27 Aug 2003 10:19:04 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210


I think that this is a very good idea!
I would definitly do part of the testing as I am working with the system here anyways. I will simply send everything to the list that could or does cause errors. I can also help with the programming of a new Java version of gift. Maybe we could start with an MRML engine as there is already work done by Steph and for the inclusions of new domains such as music retrieval it would be a good start as well. Platform independe is a factor there, too.
Should we set up a cvs somwhere to share code and work on a common version?
I think that this can go in parallel with the normal gift development.

I will try to work a bit on gift on MacOs X but I do not have access to a BSD machine.

Cheers, Henning

Wolfgang Müller wrote:

Hi GIFTies,

Triggered by the giFT/GIFT discussion, as well as Josh's mails, I would like to propose a roadmap for future GIFT development.

Lately, Steph and Henning have made suggestions off-line (they wrote a paper) concerning improvement of MRML. Steph has backed this up with his MRML 2 standard proposal, and an architecture implemented in JAVA that goes with it, and that is currently done in Geneva, by Tayeb, a diploma student.

This would mean, that in the long run, GIFT would be rather written in JAVA than in c++. In the short run, I would volunteer to write JNI and CNI (Cygnus native interface) code for making the new JAVA stuff work with the old plugins.

--What would we gain with this?--

1. At many universities I know the average student is more comfortable with JAVA than he/she is with c(++). So, this move would make finding students who would like to work on non-image-processing parts of GIFT easier.

2. In the long run, we would gain more platform independence, especially, if we consider the use of gcj, and gij, the GNU compiler/interpreter for JAVA.

I propose going a two-lane process

Fast lane: Make the current GIFT a better GIFT
1. Make gift-current rock stable. For this we need mainly contribution of testing under varying conditions. 2. Make gift-current idiot proof. We need people who contribute testing of installation unter varying conditions. Given my schedule, I do not manage to keep my system a suitable system for testing the installation, and a suitable system for fixing the bugs at the same time.
3. Make GIFT work on BSD
4. Ask for testing in the KDE community, making it fitter for use in KMRML.

It would be good to have something like that at the end of the year.

Slower lane: Get ready for replacement GIFT
1. Port functionality to some very simple pure JAVA query engine together with Tayeb's work and the proper configuration
2. Make proper interfaces between JAVA and the "old" GIFT plugin mechanism.

This goes quickly or not so quickly, depending on the number of students people manage to attract.

Are you OK with that? Any takers for testing, programming and suggestions?

help-GIFT mailing list

Dr. Henning Müller
University Hospitals of Geneva
Division of Medical Informatics
21, rue Micheli-du-Crest
CH-1211 Geneva 4, Switzerland
Tel  +41 22 372-6175
Fax  +41 22 372-8680
email address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]