[Pipet Devel] updated model

[J.W. Bizzaro]

Konrad Hinsen wrote:
> Another general class of code that is easy to integrate from Python
> are the classical Unix-style command line tools (whatever language
> they are written in), i.e. programs that read from standard input
> and write their results to standard output.

This is the class for which I would use a CGI/XML approach.  I think most
analysis algorithms are not, nor need to be, interactive.  For the most part,
simple algorithms can read from stdin or a file and write to stdout or a file.


Thomas wrote:
> So the other language modules are going to communicate with the core via
> e.g. XML ?

Yes, this is one approach.  The other is to link languages to Python via C. 
If someone is willing, the best approach would be to use Python to begin with
:-)  I think this is something we need to keep working on.  The key technical
issue here is how can we make TULIP language-independent?


Konrad Hinsen wrote:
> Programs with an interactive (but non-graphic) interface can be
> integrated via PyExpect, but I have little personal experience with
> that approach.

Yes, we will consider the case for which PyExpect can be used.  But for the
core TULIP tools, we should have everything in Python or C, with a strong
emphasis on Python:  The only situations where C should be used are (1) for
compute-intensive routines, and (2) custom GTK widgets (otherwise, I would
like to use the standard Python-GTK widget bindings).


Konrad Hinsen wrote:
> With graphical interfaces I see no reasonable solution
> at all.

But even graphical programs can utilize stdin and stdout.  If they can do
that, we have communication.


Konrad Hinsen wrote:
> We might consider C translations (via f2c) of Fortran tools as well.
> If people want the extra performance given by a real Fortran compiler,
> they can always get the Fortran code and take care of the installation
> themselves.

Konrad, you mentioned that you can link Fortran and C, and then wrap the C in
Python.  Is that right?  Can you give us some details?


Thomas wrote:
> But I can imagine testing something else too ... after all the GIMP's basic 
> model has some similarities to TULIP - and the GIMP made REALLY progress
> .. so why not ? 

Yes, I actually used to say that on the Web site.  Interesting you should
notice that.  And I too have heard of the GIMP being ported to Windows.


Konrad wrote:
> The most serious issue could be the multiplatform support. Personally
> I am happy with Unix, but I know that more and more people are forced
> to use Windows, even if they don't like it. It would be good to know
> how GTK is going to develop. Does anyone have insider information on this?

TULIP is meant to be extremely graphical and easy to use, much like the Mac. 
This is because most molecular biologists (in my opinion) are not the type to
want to work with cryptic commands.  I think this need by molecular biologists
for graphical applications led to the ubiquity of Macs in the lab.  I don't
know about where you guys work, but all we have in the labs here are Macs.  I
therefore believe a port to the Mac may be more important than a port to Windows.

Regarding how we will make the transition from UNIX to Mac or Windows, we
probably all agree that Python is the key: The more Python we use over the
binary stuff, the easier our port will be.  As far as GTK is concerned, I too
think that it may be a matter of time before it is ported to Windows and Mac. 
So, by the time TULIP is ready, we may already have GTK on these platforms.

By the way, Konrad, what do you think we need for structural analysis in the
*core* distribution of TULIP...the most important tools that may be accessed
by other tools?


Jeff
-- 
J.W. Bizzaro                  Phone: 617-552-3905
Boston College                mailto:bizzaro at bc.edu
Department of Chemistry       http://www.uml.edu/Dept/Chem/Bizzaro/
--