Lars,
The current way of compiling and linking program source code works
fine for programmers. The component software concept exemplified by
Java Beans and OpenDoc extends program building to non-programmers.
This is something that can be very helpful
for an average biologist, who couldn't program out of a paper bag,
but who could drag & drop program components (a sequence reader like
readseq, various sequence manipulators, reporter components)
into an application skeleton (bean bag) to create an application that
does just the data analysis s/he wants. This goes forward along
the lines I've been trying to develop my general sequence
editor, seqpup, as an expandable, user-customizable tool.
The people who currently use 'readseq' the application seem to
be more the programmer/bioinformatics system manager type. It
has a useful unix-command-line interface for those who care
to deal with such. But my experience with biologists leads me to
think that readseq's functions are more accessible to them
when packaged into a helpful user interface that doesn't rely
on command-line operations.
Also, if we can believe in the views of future for Java software
that are being hyped now, the average bioinformatics system manager
will also start using Java components to build server applications.
Somewhere in the future, an average bioinfo server will have Java
everywhere: java-corba/sql interfaces to commercial databases,
java components in place of http-cgi scripts, and other complex
analysis tools built from components that include java subsets.
If/when that time comes, a component like readseq that is built
in a fashion that it can be linked with other components automatically
will have definite value (it will take much less of a talented
person's time to deal with).
It remains to be seen if some of these predictions come true, but
I find the vision and plans for such component software based
in Java to be compelling.
-- Don
In article <yuewwms6ahm.fsf at turing.nada.kth.se>,
Lars Arvestad <arve at nada.kth.se> wrote:
>>Don Gilbert wrote:
> DG> These include runtime reference resolution such that I can
> DG> potentially make readseq a portable component that any non-programmer
> DG> or interested biologist could drop into an application container
> DG> and link together with other program parts to form a new
> DG> application. This is part of what Java Beans is about. One
> DG> can't do this with C++ or C code. It is something new and
> DG> potentially very enabling for the average scientist or
> DG> bioinformatician.
>>I don't understand this comment. What is wrong with the function
>libraries in the old fashion way? With readseq already being quite
>portable (right?), it should be easy enough to build a library with
>it.
--
-- d.gilbert--biocomputing--indiana u--bloomington--gilbertd at bio.indiana.edu
