From bizzaro at geoserve.net Thu Feb 3 15:12:56 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:11 2006
Subject: [Pipet Devel] mail is back
Message-ID: <3899E148.A36D8B3D@geoserve.net>
Greetings.
You may have experienced problems trying to send mail to this list. This is
because we changed the server name, and some configurations needed to be
updated. But all is working now.
You can continue to post messages to
@bioinformatics.org
But the following addresses will work as well:
@bioinformatics.org
@www.bioinformatics.org
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| THE OPEN LAB |
| Open Source Bioinformatics |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 3 16:35:06 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:11 2006
Subject: [Pipet Devel] bioinformatics for the visually impared
Message-ID: <3899F48A.D89659A5@geoserve.net>
Locians,
The last time Gary and I met, we brainstormed a way to control Loci using
natural language. This is what we've been calling the 'NLI' (Natural Language
Interface - more on this later). Well, it looks like the control of Loci, via
talking and listening to it, is coming to a GNU/Linux system near you.
First, speech recognition:
"CMU Sphinx (the speech recognition software being developed at CMU being
funded by DARPA and NSF for the last 15 years) has gone open source and is up
for download on SourceForge. You can check out the announcement, go to the
home page at CMU, or download the code for yourself. It should build
out-of-box on several platforms, linux, freebsd, sun4m, etc. - but work is
still needed. Help with documentation would be greatly appreciated, too. It's
important that people grab this stuff ASAP, too, just in case some people
decide to go after it for potential patent violations (we all know how much
people love the patent system)."
http://slashdot.org/article.pl?sid=00/01/31/0848243&mode=flat
And what use is having Loci listen to you, if it can't talk back?
"When thinking of Linux, the words 'user friendly' do not generally come
immediately to mind. Therefore, one might be surprised to learn that Linux 2.4
(and some later editions of the Linux 2.2 kernel) supports speech synthesizer
cards. This driver and the appropriate hardware will allow vision-impaired
Linux users to hear all Linux output, including messages very early in the
boot process. Very few Operating Systems can boast such low level support for
these devices. (There will be other patches and utilities that will be
required for full use of these devices, this kernel driver is only a component
of the system.)"
http://linuxtoday.com/stories/15936.html
So, how about bioinformatics for the visually impared?
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| THE OPEN LAB |
| Open Source Bioinformatics |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Sun Feb 6 13:05:01 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:11 2006
Subject: [Pipet Devel] inside ole ps version
Message-ID: <200002061805.LAA03952@redpoll.pharmacy.ualberta.ca>
From gvd at redpoll.pharmacy.ualberta.ca Sun Feb 6 13:14:40 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:11 2006
Subject: [Pipet Devel] inside ole ps version
In-Reply-To: <200002061805.LAA03952@redpoll.pharmacy.ualberta.ca> from "Gary Van Domselaar" at Feb 06, 2000 11:05:01 AM
Message-ID: <200002061814.LAA03993@redpoll.pharmacy.ualberta.ca>
Whups! Where did the body of that message go?
Oh, here it is:
I found this little gem on the gnome-components mailing list:
I have setup a ps version of inside ole.
The preface is missing as well as some notes but well...
http://www.stud.enst.fr/~lacage/gnome/inside-ole.ps.gz
This (811 page! okay its not so little) book provides in-depth coverage of
Micro$oft's component software integration environment OLE, including the
common object model (COM). GNOME uses this model as the basis
for bonobo.
Enjoy!
g.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Gary Van Domselaar gvd@redpoll.pharmacy.ualberta.ca
Faculty of Pharmacy Phone: (780) 492-4493
University of Alberta FAX: (780) 492-5305
Edmonton, Alberta, Canada
From bizzaro at geoserve.net Wed Feb 9 00:18:05 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:11 2006
Subject: [Pipet Devel] excerpt from CHANGES
Message-ID: <38A0F88D.970D6440@geoserve.net>
Sorry if I'm posting this sooner than you'd like. I wanted to comment on some
things (next message).
2/8/00 Brad
* Got all of the below database stuff working for MySQL, PostgreSQL and
Gadfly (at least, it seems to be working okay for my simple examples).
Shouldn't be too hard to add more dbs if people want them...
2/7/00 Brad
* Can now drag and drop databases and tables.
* Created a table_view widget (just a CList with mutliple columns--it
appears that that is the most widely used widget to display database
contents). Dragging a table out of a container onto the desktop shows its
contents in the table view widget.
* Got the list and tree representations working for viewing database
contents.
* file_select widgets now update their xml to try and keep the xml current
with the file located in the selection widget.
2/6/00 Brad
* Now you can view database information in a container in tree view only.
* Started working on dragging databases and tables out of a container onto
the desktop.
2/4/00 Brad
* Changed up the buttons on container to get ready to add database info to
containers.
* Started adding database connection utilities. Right now I'm working with
MySQL and MySQLdb since I've already got MySQL with tables filled on my
computer. So far, there is a basic database selection window that pops up.
A connection is then established with the database.
* Did some internal stuff to get more working. Will continue on this...
2/1/00 Brad
* Added drag and drop stuff so that you can now drag items out of a
container unto any workspace. A new locus will be created for the dragged
item on the workspace that it is dragged to. The locus contains the
information from the dragged item in the container. For now, this only
works for documents and containers (since containers can only currently
hold documents and containers).
1/31/00 Brad
* Did a lot of messing around with the problem of losing clicks from
internal windowlets to the main workspace. Discovered the problem, and
thought up a solution:
Problem: What is happening is that the events from a windowlet gui are
being passed on to the parent widget (the main workspace) and then are
being taken care of again by a second event handler. To add onto this
problem, the coordinates (ie. event.x, event.y) of the event in the
mainworkspace are the same as the coordinates in the internal workspace,
so the main workspace recieves an event that it thinks is happening on a
location in its workspace that is not behind the windowlet window, but at
the relative position in its window that the event happened in the
windowlet window. Ugly problem! Although this happens for every click on
the windowlet, currently the only problem it causes is with the button 3
click to open a menu. Two menus will be opened--one for the internal
windowlet, and then one for the main workspace.
Solution: Attached an event handler to the gui which returns TRUE if
a button 3 click is recieved. This prevents the signal from being
propogated past the initial menu click.
Problem with the Solution: This solution also prevents button 3 clicks from
being propogated to loci within an internal windowlet. So we can't use a
button 3
click for anything specific to a loci, or within a GUI.
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Wed Feb 9 00:58:10 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:11 2006
Subject: [Pipet Devel] excerpt from CHANGES
References: <38A0F88D.970D6440@geoserve.net>
Message-ID: <38A101F2.FC6585F3@geoserve.net>
First, thanks for the continued work on the project, Brad.
> 2/8/00 Brad
> * Got all of the below database stuff working for MySQL, PostgreSQL and
> Gadfly (at least, it seems to be working okay for my simple examples).
> Shouldn't be too hard to add more dbs if people want them...
So, you have list and tree views of MySQL, PostgreSQL and Gadfly? Very nice.
> 2/7/00 Brad
> * Can now drag and drop databases and tables.
I don't use a DBMS on my system. Could we provide a small, test
database/table for the 3 you wrapped?
I noticed the DnD, and I'm pleased to see that you tackled the problem first,
since I have no experience with it.
> * Created a table_view widget (just a CList with mutliple columns--it
> appears that that is the most widely used widget to display database
> contents). Dragging a table out of a container onto the desktop shows its
> contents in the table view widget.
Does the table show up as a file in the 'filesystem view' or as an icon in the
'database view'?
Also, I think we should have one 'view' per container. 'Filesystem' and
'database' are really 2 different container types. We need to think on a much
lower level than we are. Instead of one program called 'container' that has
many different functions, we need to have many different containers that have
one function each.
> * Got the list and tree representations working for viewing database
> contents.
> * file_select widgets now update their xml to try and keep the xml current
> with the file located in the selection widget.
Again, per our earlier conversations, the Loci user will be limited to what
part of the filesystem he/she can access. By default, we want 4 filesystem
containers on the workspace (akin to disk dirves on a Mac desktop):
(1) $LOCIHOME/back/public/container/
(2) $LOCIHOME/back/private/container/
(3) $HOME/loci/back/public/container/
(4) $HOME/loci/back/private/container/
They appear on the workspace everytime Loci is started, and they cannot be
deleted/trashed. And for security, the user CANNOT change to a parent
directory.
A 'trash container' is another one we need to make.
> 2/6/00 Brad
> * Now you can view database information in a container in tree view only.
> * Started working on dragging databases and tables out of a container onto
> the desktop.
>
> 2/4/00 Brad
> * Changed up the buttons on container to get ready to add database info to
> containers.
> * Started adding database connection utilities. Right now I'm working with
> MySQL and MySQLdb since I've already got MySQL with tables filled on my
> computer. So far, there is a basic database selection window that pops up.
> A connection is then established with the database.
> * Did some internal stuff to get more working. Will continue on this...
>
> 2/1/00 Brad
> * Added drag and drop stuff so that you can now drag items out of a
> container unto any workspace. A new locus will be created for the dragged
> item on the workspace that it is dragged to. The locus contains the
> information from the dragged item in the container. For now, this only
> works for documents and containers (since containers can only currently
> hold documents and containers).
I like it! It's just what I was thinking about :-)
About document loci: It'd be nice if text documents had a 'text viewer'
(non-editable editor) widget in the windowlet by default. You have the
filename in the windowlet and a way to change the file affiliation of the
locus. But, by the design model I've been beating everyone over the head
with, the user should not be able to change affiliation. Just like in the
Mac, if you have an icon representing a particular file, you can't change it
so that it represents something else.
> 1/31/00 Brad
> * Did a lot of messing around with the problem of losing clicks from
> internal windowlets to the main workspace. Discovered the problem, and
> thought up a solution:
> Problem: What is happening is that the events from a windowlet gui are
> being passed on to the parent widget (the main workspace) and then are
> being taken care of again by a second event handler.
BUT, here's the catch: This doesn't always happen. It seems there is an
invisible event-catching box that doesn't always line up with the windowlet.
Try clicking all around on some windowlets. Sometimes there is a corner that
won't let the super-workspace catch the event.
> To add onto this
> problem, the coordinates (ie. event.x, event.y) of the event in the
> mainworkspace are the same as the coordinates in the internal workspace,
> so the main workspace recieves an event that it thinks is happening on a
> location in its workspace that is not behind the windowlet window, but at
> the relative position in its window that the event happened in the
> windowlet window. Ugly problem!
Indeed.
> Although this happens for every click on
> the windowlet, currently the only problem it causes is with the button 3
> click to open a menu. Two menus will be opened--one for the internal
> windowlet, and then one for the main workspace.
I know, that stinks. It looks like the pop-up menu got stuck.
> Solution: Attached an event handler to the gui which returns TRUE if
> a button 3 click is recieved. This prevents the signal from being
> propogated past the initial menu click.
Hmmm.
> Problem with the Solution: This solution also prevents button 3 clicks from
> being propogated to loci within an internal windowlet. So we can't use a
> button 3
> click for anything specific to a loci, or within a GUI.
Well, I'll try to take a crack at the problem.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From chapmanb at arches.uga.edu Wed Feb 9 10:04:55 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] excerpt from CHANGES
Message-ID: <200002091507.KAA92374@archa12.cc.uga.edu>
> First, thanks for the continued work on the project, Brad.
The pleasure is all mine--thanks for taking a look at things!
>> 2/8/00 Brad
>> * Got all of the below database stuff working for MySQL, PostgreSQL
and
>> Gadfly (at least, it seems to be working okay for my simple
examples).
>> Shouldn't be too hard to add more dbs if people want them...
>
> So, you have list and tree views of MySQL, PostgreSQL and Gadfly?
Very nice.
Right, I just did this because they seemed like 3 good ones to try. If
anyone is using other databases and would like me to get those
working, just let me know!
>> 2/7/00 Brad
>> * Can now drag and drop databases and tables.
>
> I don't use a DBMS on my system. Could we provide a small, test
> database/table for the 3 you wrapped?
Sure, MySQL and PostgreSQL will be a little more of a pain, since they
require installation and getting them running and all that jazz, so I
just provided a simple one for Gadfly. Gadfly is written in all
python, and isn't hard to install and get running. I'll send a
separate e-mail after this about it with a script to create a really
simple database. If you try it out, you'll notice that it also reveals
a current problem I'm having with Gadfly.
> I noticed the DnD, and I'm pleased to see that you tackled the
problem first,
> since I have no experience with it.
I basically just looked at dnd.py from the pyGtk examples and tried to
figure out what was going on there. I really needed to get this
working in order to get
the database stuff working, so that is what I tried to hit it first
(plus, I think it is pretty neat to be able to drag and drop things!).
I have a question on this for you. I would like to add it so that
you can also drag and drop loci from the workspace into a container
(as opposed to out of a container onto the workspace). This would also
allow us to drag loci between different workspaces (notice now how you
can drag a loci out of a container into any workspace inside the main
workspace. Pretty neat, and I didn't even have to try to do this). My
question is, what kind of button press or button press/key stroke
combo should I use to do this? I was thinking Shift:button1 click
or Control:button1 click or something like that--do you have a
preference/opinion on this?
To do the dnd into containers "properly" we'll also need to make
deletion of loci possible (otherwise it'll be more like copying loci
around), but hopefully that shouldn't be too bad.
>> * Created a table_view widget (just a CList with mutliple
columns--it
>> appears that that is the most widely used widget to display database
>> contents). Dragging a table out of a container onto the desktop
shows its
>> contents in the table view widget.
>
> Does the table show up as a file in the 'filesystem view' or as an
icon in
> the
> 'database view'?
The table is created in a separate document type loci. Basically, my
idea for getting at a table in a database is this:
1. Open up a container loci and click on the database button to
connect to a DB.
2. Once connected, the container will be filled with all of the
databases within the big database.
3. To get at the info in one of these databases, you drag it out onto
the workspace and this will create a new container for the database,
filled with all of the tables in the database.
4. Drag one of these tables out into the workspace, and a document
loci type will be created with the "table_view" widget containg the
column names and all of the info in the columns.
> Also, I think we should have one 'view' per container. 'Filesystem'
and
> 'database' are really 2 different container types. We need to think
on a
> much
> lower level than we are. Instead of one program called 'container'
that has
> many different functions, we need to have many different containers
that have
> one function each.
I ?think? what I described above might be what you want, but I'm not
positive. Let me know. Eventually, what I hope to have is that
dragging a table onto the workspace just creates a loci with a simple
widget showing some information about the table (ie. column names and
type of information they store, number of records, etc.) and then if
you hook the table up to a viewer, this will show all of the data.
That way, you can work with a huge table without having to show
everything in it.
In terms of the list vs. tree view. I'm just keeping them both
going so we can decide between them later. They both show exactly the
same thing now (since I'm not delving into directories or databases
because it is too slow). I might just switch to the list, but it is
giving me issues with the drag and drop. Notice how when you drag
something from a list view the pixmap that is shown is not the one
from the container, but this random big pixmap that I have no idea
where it came from. I can't figure out why this is happening...
> Again, per our earlier conversations, the Loci user will be limited
to what
> part of the filesystem he/she can access. By default, we want 4
filesystem
> containers on the workspace (akin to disk dirves on a Mac desktop):
>
> (1) $LOCIHOME/back/public/container/
> (2) $LOCIHOME/back/private/container/
> (3) $HOME/loci/back/public/container/
> (4) $HOME/loci/back/private/container/
>
> They appear on the workspace everytime Loci is started, and they
cannot be
> deleted/trashed. And for security, the user CANNOT change to a
parent
> directory.
Do you think we need this for using Loci on a "local" system? It seems
like you should be able to, and would want to be able to, access all
of the files/programs on your system from loci. However, when you
connect to a remote loci, you can only see the directories inside of
loci home. Am I making any sense? I had an idea about this earlier
that I posted--I'll resend that right after this.
> A 'trash container' is another one we need to make.
Do we want a trash container or do we want to use the delete option
from the menu?
> About document loci: It'd be nice if text documents had a 'text
viewer'
> (non-editable editor) widget in the windowlet by default. You have
the
> filename in the windowlet and a way to change the file affiliation
of the
> locus. But, by the design model I've been beating everyone over the
head
> with, the user should not be able to change affiliation. Just like
in the
> Mac, if you have an icon representing a particular file, you can't
change it
> so that it represents something else.
That's true... The reason I added the file selection is so that you
could get at a file directly if you added a document widget directly
onto the workspace. Also, I thought this would be needed if you wanted
to use the document widget to supply a file for command line
construction.
WRT the text viewer--that should be no big deal to do, but do you
want this contained in the "document" widget or as a separate viewer
widget? It just seems like it might be annoying to have to load the
contents of a file every time you want to refrence it, especially if
you have huge text files like some FASTA file or something.
> BUT, here's the catch: This doesn't always happen. It seems there
is an
> invisible event-catching box that doesn't always line up with the
windowlet.
> Try clicking all around on some windowlets. Sometimes there is a
corner that
> won't let the super-workspace catch the event.
I'm not sure, but this might have to do with the problem of the actual
position of a loci not being identical to it's world coordinates. I
tried to use c2w() to convert the canvas coordinate refrences to
world coordinates, but I always get a seg fault when I try to use it.
Not sure why...
>> Problem with the Solution: This solution also prevents button 3
clicks from
>> being propogated to loci within an internal windowlet. So we can't
use a
>> button 3
>> click for anything specific to a loci, or within a GUI.
>
> Well, I'll try to take a crack at the problem.
That would be great! At least right now things seem to go fairly
normally and you don't accidentally end up adding loci to the wrong
workspace, but a better solution would definately be spectacular :-)
Brad
From chapmanb at arches.uga.edu Wed Feb 9 10:20:27 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Gadfly info
Message-ID: <200002091523.KAA44896@archa11.cc.uga.edu>
Okee dokee, here's the little bit I know about getting Gadfly running.
1. Go get Gadfly from: http://www.chordate.com/gadfly.html
2. Follow the install instructions to get it running.
(http://www.chordate.com/kwParsing/gadfly.html). It's written in all
python, so just unpack it in your classpath and run one python command.
3. Either use the test script provided with Gadfly or my little test
script (with comments) at the bottom of this page, to create a
database. The trick is that you have to create a directory to store
the database info in. I have been using '/usr/local/gadfly/data' to
store my stuff. If you want to use this, you have to create this
directory. If you want to use something else, you have to change the
gadflyDir variable in my test script below, and also go to
loci/main/library/modules/const.py and edit the gadflyDirectory
variable there (there is a note about this in the INSTALL file).
4. Okay, now you have a database created and are ready to look at in
loci so start up loci in the usual manner.
5. Create a container loci. Click on the DB button, and you'll be
presented with a dialog to enter info about the database to connect to.
6. For gadfly, it is really easy--just type in gadfly in the database
type box, and click OK.
7. The container widget should now have a loci inside of it with your
test database. To look at its contents, click on it, and then drag it
onto the workspace.
8. Now open up the new container, and you'll see the tables in the
database. Click on the created table, and drag it onto the workspace.
9. Now you should have a document loci representing that table. Double
click on it, and you should see a widget displaying the columns and
the info in each column. Of course, now you can also see a current bug
(sorry!). Gadfly doesn't return the column info in the manner in which
its inserted in the database--I just started using Gadfly, and I'll
need to play around with it more to fix this.
10. Ta Da, that's it!
Please let me know if you have any problems/comments. My next thing to
work on will be inserting information into databases, so hopefully
very soon we shouldn' t have to worry about test scripts/etc--it will
all be able to be done from Loci. Yay!
Brad
Test Script
-----------
# Note: you'll probably need to fix up the indents on this.
#!/usr/bin/env python
import sys
def main(argv):
"""
A little python script to create a gadfly database.
"""
# The directory where gadfly DBs should be stored.
# This directory *must* already exist, and be writable and all that.
gadflyDir = '/usr/local/gadfly/data'
# connect to gadfly
import gadfly
connection = gadfly.gadfly()
# make the database
connection.startup("LociTestDB", gadflyDir)
# create a cursor to do things with the database
cursor = connection.cursor()
# create a table
tableSQL = "CREATE TABLE ILikeLoci(col1 varchar, col2 varchar, col3
varchar, col4 integer)"
cursor.execute(tableSQL)
# insert something in the table
insertSQL = "INSERT INTO ILikeLoci(col1, col2, col3, col4) values
('Loci', 'is', 'number', 1)"
cursor.execute(insertSQL)
insertSQL2 = "INSERT INTO ILikeLoci(col1, col2, col3, col4) values
('My', 'Biochem', 'Grade', 23)"
cursor.execute(insertSQL2)
# commit the changes and close the connection
connection.commit()
connection.close()
print 'Now you've got a Gadfly database! Try to contain your
excitement.'
return 0
if __name__ == '__main__':
sys.exit(main(sys.argv))
From chapmanb at arches.uga.edu Wed Feb 9 10:22:30 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Resend of earlier message
Message-ID: <200002091525.KAA86250@archa12.cc.uga.edu>
This is just a resend of some rambling that I did earlier. Thought it
might be relevant to the $LOCI_HOME stuff. I know some of the stuff I
thought then is wrong (sorry!) but hopefully it might make some sense
:)
Hey all. I just had a random thought on the private versus public
program
loci issue (sorry that it is so late into the design of the directory
structure). What I was thinking is that maybe public versus private
isn't
specific enough for setting loci/program availability.
For a bioinformatics example, you might have a database of
information that hasn't been published, but that you would like to
share
with your collaborators. Or similary, you might have a program you are
developing that isn't bug free, but you would like some of your
friends who
use Loci to help try out for you. Then you wouldn't want it to be
publicly
accessable, for fear that some evil crackers would try to crash your
system
using an undiscovered bug, but would like to let it be used by a
restricted
number of people.
Okay, so I thought up a way to try and make this possible:
1. When a program is being ported to Loci, it will need to have some
kind
of Loci specific file describing it, like the meta-data files of
Applab or
the *.acd (I think--don't really know much about EMBOSS, sorry if I'm
wrong!) files for EMBOSS. This file will likely be in XML like
everything
else and have info about the program including the widgets it wants,
command line options, etc. Well, why not have an additional line that
specifies something like:
public
In this way the loci users could set a locus to have specific
availability,
such as a group of collaborators on a project, ie.
top_secret_HIV_project
2. When a remote user connects to another computer, they will need to
authenticate themselves (through CORBA authentication stuff, I assume)
with
a
name and password (if they are not registering as a public guest).
3. Then when a remote user asks the Loci program for a list of
available
programs/databases/etc. they will be passed all available loci. So if I
logged in as guest, I would only see the publically available loci,
while
if I logged in under a user name and was put into the
top_secret_HIV_project group, I would see publically available loci
and the
top_secret_HIV_project specific loci.
So what does everyone think? Stupid idea? Good idea?
Have-you-been-up-for-six-days-straight-doing-nothing-but-smoking-crack
idea?
Brad
From bizzaro at geoserve.net Wed Feb 9 23:46:13 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] mouse buttons (was: excerpt from CHANGES)
References: <200002091507.KAA92374@archa12.cc.uga.edu>
Message-ID: <38A24295.3A5C8F02@geoserve.net>
(I'm going to split this discussion up into several messages.)
Brad Chapman wrote:
> I have a question on this for you. I would like to add it so that
> you can also drag and drop loci from the workspace into a container
> (as opposed to out of a container onto the workspace). This would also
> allow us to drag loci between different workspaces (notice now how you
> can drag a loci out of a container into any workspace inside the main
> workspace. Pretty neat, and I didn't even have to try to do this). My
> question is, what kind of button press or button press/key stroke
> combo should I use to do this? I was thinking Shift:button1 click
> or Control:button1 click or something like that--do you have a
> preference/opinion on this?
Okay, I recognized a while back that we would have a problem with DnD. We
simply have a conflict between the way X DnD works and how my own workspace
DnD works. From my understanding, dragged objects in X 'leave' their parent
window so that they can be dropped anywhere in the X environment. However, I
already set the workspace up to allow the (nifty) dragging of loci (icons,
etc.) with connectors attached. This, my own form of DnD, is limited to the
workspace (Gnome canvas) itself AND WILL NOT EVEN WORK BETWEEN WINDOWLETS
(because each X widget is usually its own little X window, including the
canvas).
So, you can see why Brad has a problem doing DnD _from_ the workspace, _to_ a
container windowlet. When you drag a locus toward a container, you're using
my workspace DnD and not X DnD, and the locus simply won't go across the
boundary of the windowlet (enter another X window).
The obvious solution is to switch off the workspace DnD and use X DnD. This
is why Brad suggested using a combination of a key press with a mouse button
press. But I want to make DnD consistent for movement both to and from
windowlets.
I therefore propose that my own workspace DnD be controlled via mouse button 2
(middle) press, and have button 1 (left) press control X DnD. I think this is
more standard to how X applications work.
So, this is what each button should do:
BUTTON 1 (left)
===============
Event Over Results in
----- ---- ----------
Click Locus Select locus
Click Workspace Deselect all loci
(select workspace)
Press+DnD Locus X Windows DnD of locus
Press+DnD Workspace Rectilinear select
Double click Locus Open/close windowlet
Double click Workspace (nothing)
BUTTON 2 (middle)
===============
Event Over Results in
----- ---- ----------
Click Locus (nothing)
Click Workspace (nothing)
Press+DnD Locus DnD of locus, limited
to workspace
Press+DnD Workspace 'DnD' (scroll) of workspace
(see Adobe Acrobat Reader)
Double click Locus (nothing)
Double click Workspace (nothing)
BUTTON 3 (right)
===============
Event Over Results in
----- ---- ----------
Click Locus Pop-up menu
Click Workspace Pop-up menu
Press+DnD Locus (nothing)
Press+DnD Workspace (nothing)
Double click Locus (nothing)
Double click Workspace (nothing)
Now when we do a button 1 (left) X DnD of a locus within or onto the
workspace, we will need to know where (xy) it is dropped, and then the locus
(icon, etc.) and connectors will be moved there.
Also, Brad, I was planning on having custom cursors with this Gtk interface.
Look in an older loci-core module for cursor.xpm. I like the way Adobe
Acroread has the hand cursor (especially how you can 'grab' the background to
scroll it), and I want to do something like that for Loci. Newer versions of
gnome-libs will have functions for selecting custom cursors, so we can
implement this then.
Questions?
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 10 01:43:46 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] L&H unveils Linux speech engine
Message-ID: <38A25E22.6AA0A77D@geoserve.net>
Pertaining to our NLI:
http://www.theregister.co.uk/000209-000006.html
Jeff
From bizzaro at geoserve.net Thu Feb 10 03:41:17 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] another potential Locian
Message-ID: <38A279AD.9103F7C3@geoserve.net>
Leyland Needham seems to be thinking along the same line as we. Here is an
excerpt from an article of his (audio is just an example):
------------------------
Say for example, I wanted to create an audio player, I would be able to use a
ram memory block for holding audio remembered from the hard drive, and attach
an audio server to it, then create a window from a gui server and place
buttons on the windows that each individually attach to the diffrent functions
of an audio server connection and create a button and attach it to the memory
system so that once that is done I can tell it what audio memory to remember
from the hard drive by clicking the remember button, and then click play to
have it play the piece of audio. If I wanted to view a scope of the audio data
as it plays I could attach one to the interface (any where I want) and connect
it to the audio servers connection. The same could be done for spectral
analysis.
-------------------------
http://members.aol.com/suboner/articles/Advancement.html
http://members.aol.com/suboner/articles/Advancement2.html
I guess I should contact him.
Jeff
From chapmanb at arches.uga.edu Thu Feb 10 08:47:55 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] mouse buttons (was: excerpt from CHANGES)
Message-ID: <200002101351.IAA46298@archa12.cc.uga.edu>
[explanation of Loci DND vs. X window DND]
>
> So, you can see why Brad has a problem doing DnD _from_ the
workspace, _to_ a
> container windowlet. When you drag a locus toward a container,
you're using
> my workspace DnD and not X DnD, and the locus simply won't go across
the
> boundary of the windowlet (enter another X window).
Thanks for your description of the problem. Very clear!
> I therefore propose that my own workspace DnD be controlled via
mouse button 2
> (middle) press, and have button 1 (left) press control X DnD. I
think this is
> more standard to how X applications work.
The thing that I worry about is us poor users of cheap mice lacking a
middle button. If there a standard key/click combo for X-windows to
get a button 2 click if you are missing button 2? (Hey, you have to
remember--I'm used to the ol' Mac single button mice :-)
> So, this is what each button should do:
[table o' button clicks and results]
The thing you really don't address is connecting loci together on a
single workspace and how this would work in the new button scheme?
Would this be a button 2 click as well? It seems to me that the major
thing a user will be doing in Loci is moving loci around within a
single workspace and connecting them. To me, moving a loci to a new
workspace, or even dragging it to a container is an "unusual" event,
and this should be stuck with a more non-standard button press.
> Also, Brad, I was planning on having custom cursors with this Gtk
interface.
> Look in an older loci-core module for cursor.xpm. I like the way
Adobe
> Acroread has the hand cursor (especially how you can 'grab' the
background to
> scroll it), and I want to do something like that for Loci. Newer
versions of
> gnome-libs will have functions for selecting custom cursors, so we
can
> implement this then.
This is a very cool idea! Now we just have to figure out how to make
the windows scroll automatically...
Brad
From bizzaro at geoserve.net Thu Feb 10 11:24:05 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] mouse buttons (was: excerpt from CHANGES)
References: <200002101351.IAA46298@archa12.cc.uga.edu>
Message-ID: <38A2E624.4087CE20@geoserve.net>
Brad Chapman wrote:
>
> The thing that I worry about is us poor users of cheap mice lacking a
> middle button. If there a standard key/click combo for X-windows to
> get a button 2 click if you are missing button 2? (Hey, you have to
> remember--I'm used to the ol' Mac single button mice :-)
In X you can do button 2 (3 button mouse) emulation. You can configure it so
that clicking button 1 and button 3 simultaneously, equals clicking button 2.
The X configuration program that does this may be the same program that
configures your video card, but it may be a separate program. I don't know
what FreeBSD uses. Look into it; it's very common.
> The thing you really don't address is connecting loci together on a
> single workspace and how this would work in the new button scheme?
> Would this be a button 2 click as well? It seems to me that the major
> thing a user will be doing in Loci is moving loci around within a
> single workspace and connecting them.
That's a good point. I didn't say anything about connector/dot movement.
Considering you wouldn't do an X DnD on just the connector, we can let button
1 handle this (connector/dot movement as it is now, being non-X DnD) IN
ADDITION TO button 2. So, the user can move connectors around with either
button.
> To me, moving a loci to a new
> workspace, or even dragging it to a container is an "unusual" event,
> and this should be stuck with a more non-standard button press.
I was recently thinking about locus movement being 'quantized' or done in one
step (locus disappears from drag start location and reappears at drop
location) rather than continuous, for users with a slower system. X DnD via
button 1 would do that for us, providing we can tell where on the canvas the
drop occurs.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Thu Feb 10 11:25:40 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] another potential Locian
In-Reply-To: <38A279AD.9103F7C3@geoserve.net> from "J.W. Bizzaro" at Feb 10, 2000 08:41:17 AM
Message-ID: <200002101625.JAA16666@redpoll.pharmacy.ualberta.ca>
> I guess I should contact him.
Indeed.
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From bizzaro at geoserve.net Thu Feb 10 20:46:14 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] SVG
Message-ID: <38A369E6.E3845599@geoserve.net>
Justin et al.,
Do you know of a widget that can display just SVG graphics? I was conversing
with the Sodipodi author about this, but it seems he has no plans for making
one.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From mangalam at home.com Fri Feb 11 16:41:12 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <38A369E6.E3845599@geoserve.net>
Message-ID: <38A481F8.3A1069FA@home.com>
Hi All,
I'm working on a large-scale gene expression database and analysis project
(Open Source!) and one of teh tools that we're seriously evaluating is
IBM's Open Data Explorer (DX), now also Open Source (a requirement for the
project). It's at www.opendx.org. I just recently got it to compile and
link on my RH6 box (50+MB of code and docs)
It's a client/server visual programming environment that encapsulates some
of the ideas that have been flowing on this channel (altho it's not
Python-based). However, it does have a modularity and architecture that
looks looks a lot like Loci, and since it's Open Source, I wonder if it
couldn't be mined to exploit the functionality that Loci needs.
Has anyone here looked at it with that in mind and considered appropriating
that which could be appropriate to appropriate? It was once a commercial
(expensive!) product and it runs on most all *ixs and NT (with an Xserver)
and it has been relatively well-debugged.
The loci / module aspect of it is very intriguing.
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From gvd at redpoll.pharmacy.ualberta.ca Fri Feb 11 17:30:04 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
In-Reply-To: <38A481F8.3A1069FA@home.com> from "Harry Mangalam" at Feb 11, 2000 01:41:12 PM
Message-ID: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca>
Harry Mangalam wrote:
>
> Hi All,
Hi Harry!
>
> I'm working on a large-scale gene expression database and analysis project
> (Open Source!) and one of teh tools that we're seriously evaluating is
> IBM's Open Data Explorer (DX), now also Open Source (a requirement for the
> project). It's at www.opendx.org. I just recently got it to compile and
> link on my RH6 box (50+MB of code and docs)
I mentioned IBM's Data Explorer back in the fall. It is a very
sophisticated and powerful data visualization environment.
>
> It's a client/server visual programming environment that encapsulates some
> of the ideas that have been flowing on this channel (altho it's not
> Python-based). However, it does have a modularity and architecture that
> looks looks a lot like Loci, and since it's Open Source, I wonder if it
> couldn't be mined to exploit the functionality that Loci needs.
This is very true! If you go visit the Detailed Description page:
http://www.research.ibm.com/dx/dxDetailedDescription.html
you'll find that OpenDX's architecture and Loci's architecture are
virtually identical. A good example of convergent evolution ;-)
Here are just some of the striking similarities:
"The client process is the graphics user interface and it is always
operate on a workstation. The server process does all of the computation;
it may reside on the same of different workstation"
"The server is controlled via the data flow executive, which determines
what tasks need to be executed base upon user requests and schedules
their execution."
"The executive accepts a well-defined protocol (a script language), which
the user interface generates based upon input it receives. The executive
can be operated independently of the user interface via the
scripting/programming language."
>
> Has anyone here looked at it with that in mind and considered appropriating
> that which could be appropriate to appropriate? It was once a commercial
> (expensive!) product and it runs on most all *ixs and NT (with an Xserver)
> and it has been relatively well-debugged.
>
> The loci / module aspect of it is very intriguing.
Considering that Loci's and OpenDX's architectures are so closely aligned,
and that we have yet to hammer out the details of the 'executive', I think
we would be wise to take a peek at their code.
Regards,
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From mangalam at home.com Fri Feb 11 18:38:02 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca>
Message-ID: <38A49D5A.B2E11E1A@home.com>
Hi Gary,
> I mentioned IBM's Data Explorer back in the fall. It is a very
> sophisticated and powerful data visualization environment.
My apologies - I must have been asleep (or just ignoring everything that
wasn't necessary to my continued survival at the time...)
> >
> > It's a client/server visual programming environment that encapsulates some
> > of the ideas that have been flowing on this channel (altho it's not
> > Python-based). However, it does have a modularity and architecture that
> > looks looks a lot like Loci, and since it's Open Source, I wonder if it
> > couldn't be mined to exploit the functionality that Loci needs.
>
> This is very true! If you go visit the Detailed Description page:
>
> http://www.research.ibm.com/dx/dxDetailedDescription.html
>
> you'll find that OpenDX's architecture and Loci's architecture are
> virtually identical. A good example of convergent evolution ;-)
>
> Here are just some of the striking similarities:
>
> "The client process is the graphics user interface and it is always
> operate on a workstation. The server process does all of the computation;
> it may reside on the same of different workstation"
>
> "The server is controlled via the data flow executive, which determines
> what tasks need to be executed base upon user requests and schedules
> their execution."
>
> "The executive accepts a well-defined protocol (a script language), which
> the user interface generates based upon input it receives. The executive
> can be operated independently of the user interface via the
> scripting/programming language."
Yup - that's about what appealed to me as well.
> Considering that Loci's and OpenDX's architectures are so closely aligned,
> and that we have yet to hammer out the details of the 'executive', I think
> we would be wise to take a peek at their code.
So I'm not entirely in left field :) or if I am, at least Gary's standing
next to me.
What remains to be seen (or at least understood, from my end) is whether or
how the servers can be tied into a distributed system that is as
'self-aware' as what has been proposed for Loci. (He Wildly Waves the
Not-A-CORBA-Expert flag) I'm wondering if this awareness might be mediated
by a CORBA layer - Gary - do you know if there is a CORBA component to the
DX communication layer? There doesn't appear to be from a cursory rip thru
the docs, but even if there isn't, that might be the key component that
Loci (or NCGR) could contribute. I just posted a note to the DX list about
this.
However, Doug Schmidt (who coincidentally works at UCI, a few minutes from
me) has put together an Open Source Adaptive Communications Environment
(ACE - http://www.cs.wustl.edu/~schmidt/ACE-overview.html ) that uses CORBA
for creating distributed computing environments. The combination of the
two might be what's needed.
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From bizzaro at geoserve.net Fri Feb 11 22:27:54 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <38A369E6.E3845599@geoserve.net> <38A481F8.3A1069FA@home.com>
Message-ID: <38A4D33A.3D3E7B70@geoserve.net>
Harry Mangalam wrote:
>
> It's a client/server visual programming environment that encapsulates some
> of the ideas that have been flowing on this channel (altho it's not
> Python-based).
It's C/Motif I guess, right?
> However, it does have a modularity and architecture that
> looks looks a lot like Loci, and since it's Open Source, I wonder if it
> couldn't be mined to exploit the functionality that Loci needs.
I'll put this one in the "so much like Loci it's scarey" file.
But it is not _quite_ as general purpose as we intend Loci to be. From what I
have seen and read, it is targeted at people who produce high-end data
visualizations. I think it competes head-on with AVS:
http://www.avs.com/products/expdev/netedit.htm
And, as you can see, the editors/workspaces are similar.
DX is old though, dating back to 1991.
> Has anyone here looked at it with that in mind and considered appropriating
> that which could be appropriate to appropriate? It was once a commercial
> (expensive!) product and it runs on most all *ixs and NT (with an Xserver)
> and it has been relatively well-debugged.
>
> The loci / module aspect of it is very intriguing.
It'll be good to study it. Thanks for the heads-up.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 11 22:30:10 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca>
Message-ID: <38A4D3C2.80D08E18@geoserve.net>
Gary Van Domselaar wrote:
>
> I mentioned IBM's Data Explorer back in the fall. It is a very
> sophisticated and powerful data visualization environment.
I can't find the message or recall having heard of it :-) Are you still
shooting heroin, Gary? ;-)
> "The client process is the graphics user interface and it is always
> operate on a workstation. The server process does all of the computation;
> it may reside on the same of different workstation"
Yes.
> "The server is controlled via the data flow executive, which determines
> what tasks need to be executed base upon user requests and schedules
> their execution."
Yep.
> "The executive accepts a well-defined protocol (a script language), which
> the user interface generates based upon input it receives. The executive
> can be operated independently of the user interface via the
> scripting/programming language."
Yepper.
> Considering that Loci's and OpenDX's architectures are so closely aligned,
> and that we have yet to hammer out the details of the 'executive', I think
> we would be wise to take a peek at their code.
Agreed :-)
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 11 22:38:17 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:12 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca> <38A49D5A.B2E11E1A@home.com>
Message-ID: <38A4D5A9.56CDD50A@geoserve.net>
Harry Mangalam wrote:
>
> Yup - that's about what appealed to me as well.
So, you'll be using DX instead of Loci? :-( Of course, Loci isn't quite
ready.
> > Considering that Loci's and OpenDX's architectures are so closely aligned,
> > and that we have yet to hammer out the details of the 'executive', I think
> > we would be wise to take a peek at their code.
>
> So I'm not entirely in left field :) or if I am, at least Gary's standing
> next to me.
You're playing short-stop.
> do you know if there is a CORBA component to the
> DX communication layer? There doesn't appear to be from a cursory rip thru
> the docs, but even if there isn't, that might be the key component that
> Loci (or NCGR) could contribute.
You mean The Open Lab, unless Loci is modeled _that_ closely after DX.
What is NCGR working on?
> However, Doug Schmidt (who coincidentally works at UCI, a few minutes from
> me) has put together an Open Source Adaptive Communications Environment
> (ACE - http://www.cs.wustl.edu/~schmidt/ACE-overview.html ) that uses CORBA
> for creating distributed computing environments. The combination of the
> two might be what's needed.
I don't think this was mentioned before. I'll go take a look.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 11 22:50:31 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <38A369E6.E3845599@geoserve.net> <38A481F8.3A1069FA@home.com> <38A4D33A.3D3E7B70@geoserve.net>
Message-ID: <38A4D887.1F5CDAF4@geoserve.net>
"J.W. Bizzaro" wrote:
>
> From what I have seen and read, it is targeted at people who produce high-end data visualizations.
Looking at the image gallery, I'm reminded of our plan for OpenGL viewers.
There already are Python bindings to GtkGLArea in gnome-python.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Sat Feb 12 15:03:12 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca> <38A49D5A.B2E11E1A@home.com>
Message-ID: <38A5BC80.A80E04CA@redpoll.pharmacy.ualberta.ca>
Harry Mangalam wrote:
>
> Hi Gary,
> > I mentioned IBM's Data Explorer back in the fall. It is a very
> > sophisticated and powerful data visualization environment.
>
> My apologies - I must have been asleep (or just ignoring everything that
> wasn't necessary to my continued survival at the time...)
Hmmm.. I can't find it on the list... might have just sent it directly
to Jeff... me bad!
>
> > Considering that Loci's and OpenDX's architectures are so closely aligned,
> > and that we have yet to hammer out the details of the 'executive', I think
> > we would be wise to take a peek at their code.
>
> So I'm not entirely in left field :) or if I am, at least Gary's standing
> next to me.
Hey, we're all in this game together!
>
> What remains to be seen (or at least understood, from my end) is whether or
> how the servers can be tied into a distributed system that is as
> 'self-aware' as what has been proposed for Loci. (He Wildly Waves the
> Not-A-CORBA-Expert flag) I'm wondering if this awareness might be mediated
> by a CORBA layer - Gary - do you know if there is a CORBA component to the
> DX communication layer? There doesn't appear to be from a cursory rip thru
> the docs, but even if there isn't, that might be the key component that
> Loci (or NCGR) could contribute. I just posted a note to the DX list about
> this.
I haven't had the opportunity to examine their architecture in detail.
My assumptions were that it doesn't use CORBA/XML, essentially because
(as Jeff had mentioned) Data Explorer was developed back in the mesozoic
era (~1991), when these open standards weren't around. Loci and TOL
have invested heavily in these open standards, so IMHO the amount of
code reuse we could get out of OpenDX depends I think pretty heavily on
whether it has an open standard or proprietary data communication layer.
Regardless, the extensibility, modularity, generic data model, and
traffic scheduling issues are fundamentally important for Loci; and
implementing them properly is not trivial. OpenDX I think would make an
excellent study-model for Loci.
>
> However, Doug Schmidt (who coincidentally works at UCI, a few minutes from
> me) has put together an Open Source Adaptive Communications Environment
> (ACE - http://www.cs.wustl.edu/~schmidt/ACE-overview.html ) that uses CORBA
> for creating distributed computing environments. The combination of the
> two might be what's needed.
Thanks for the link. I glanced over it last nite, and it does look very
interesting (and complicated--my head was just swimming after reading
some of those docs!). Reccommended reading for all! I found this one
especially informative:
http://www.cs.wustl.edu/~schmidt/CACM-lessons.html
"Lessons Learned Building Reusable OO Frameworks for Distributed
Software"
Another fundamentally important issue for Loci is the capability to
handle enormous datasets efficiently. Bioinformatics is quickly reaching
the point where terabytes of data must be swung around between processes
in a distributed environment. This raises issues of multicasting,
streaming, flexible reintegration of processed data, and a lot more
stuff that I don't even really know about yet. How well do OpenDX and
ACE accomodate these issues? I really don't know. I'll explore OpenDX
and ACE, and get back to y'all on this issue when I have a get the
low-down :-)
Regards,
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From bizzaro at geoserve.net Sun Feb 13 00:51:21 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] DnD problem (was: excerpt from CHANGES)
References: <200002091507.KAA92374@archa12.cc.uga.edu>
Message-ID: <38A64659.8017BA87@geoserve.net>
Brad Chapman wrote:
>
> I might just switch to the list, but it is
> giving me issues with the drag and drop. Notice how when you drag
> something from a list view the pixmap that is shown is not the one
> from the container, but this random big pixmap that I have no idea
> where it came from. I can't figure out why this is happening...
Brad, can you post this problem to the gtk-app-devel-list@redhat.com ? The
gnome-devel-list@gnome.org may also be a place to post it. Are you
subscribed?
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sun Feb 13 01:45:39 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] documents and viewers (was: excerpt from CHANGES)
References: <200002091507.KAA92374@archa12.cc.uga.edu>
Message-ID: <38A65313.65BDC2B2@geoserve.net>
Brad Chapman wrote:
>
> WRT the text viewer--that should be no big deal to do, but do you
> want this contained in the "document" widget or as a separate viewer
> widget? It just seems like it might be annoying to have to load the
> contents of a file every time you want to refrence it, especially if
> you have huge text files like some FASTA file or something.
You're absolutely right, Brad, and I'm wrong. The fact that you're correcting
me on the paradigm shows that you're catching on :-)
DOCUMENTS WILL NOT HAVE A VIEWER IN THEIR WINDOWLETS. Documents are holding
places for the data, which are transient and ephemeral.
To give a document a viewer, the user would have to connect an appropriate
viewer to the document and make a composite of the two. Hmmmm. But could
Loci produce these document-viewer composites automagically, according to mime
types??? Interesting.
> The reason I added the file selection is so that you
> could get at a file directly if you added a document widget directly
> onto the workspace.
Documents represent data that are being held in the filesystem somewhere. So,
Brad is right that the path is important. But I still maintain that documents
can't change their association with a filesystem file. They should be treated
as Mac icons, as I mentioned before. I would put the path in a label widget
rather than an edit box.
> Also, I thought this would be needed if you wanted
> to use the document widget to supply a file for command line
> construction.
I kept changing my mind about how files can be added to the command-line, but
I think I've settled on using two different loci:
(1) Document locus: I/O capable locus that represents data being held
on the filesystem. An important feature of the document locus is
that it can redirect data flow (pipe).
(2) Command-line infile/outfile locus: Provides the location of the file
to the command-line (prints out a string) and redirects data flow
(pipe) to a standard document locus.
Recall Gary's example command-line:
x-povray -I /path/to/temp.def.ini /path/to/temp.my_povray_file.pov
Here I've reposted the Loci way to construct this command-line:
---->(1)+----------+
---->(2)| x-povray |
+------------------------------------------------------------------+
| | | |
| (workspace) \|/ \|/ |
| (1) (2) |
|+-----------+ +------+ +---------+ +---------+ |
|| processor | ---> | flag | -----> | infile | -----> | infile | |
|+-----------+ +------+ +---------+ +---------+ |
|| x-povray | | -I | |
|+-----------+ +------+ |
+------------------------------------------------------------------+
Each COMMAND-LINE INFILE LOCUS has 2 connectors: one is 'string adding'
(unlabeled) and the other is piping (labeled 1 and 2).
Both piping (1 and 2) connectors are disconnected. So, they appear on the
composite locus:
+----------+
---->(1)| x-povray |
---->(2)+----------+
(windowlet closed)
Now, connect the documents to the respectively numbered input connector:
+------------+ +-----------+
| document | ---->(1)| x-povray |
+------------+ >(2)+-----------+
| def.ini | /
+------------+ /
/
+------------+
| document |
+---+------------+---+
| my_povray_file.pov |
+--------------------+
You see, document loci and command-line infile loci are different.
Document loci can provide filesystem path information to other connected loci,
but they can't go in-line with other command-line constructing loci. These
command-line constructing loci (1) spit a string of text out to the
command-line and (2) gather data from stdout for piping. They can also (3)
pipe in data and use them as stdin. I didn't show that in the example, but it
would mean 2 more connectors for the command-line processor:
| (2)
| /|\
\|/ |
(1) |
+-----------+ +------+
| processor | --->(3) | flag | ----->
+-----------+ +------+
| x-povray | | -I |
+-----------+ +------+
Here, connector (1) is a stdin piping type connector, (2) is a stdout piping
type connector, and (3) is a text string adding (used in all command-line type
loci) type connector.
If (1) and/or (2) are left unconnected when a composite is made, they'll
appear on the composite's icon.
Not also that the processor in this example is a special command-line
processor type locus with a string adding type connector. So, what makes a
locus a command-line locus? IT HAS A STRING ADDING CONNECTOR.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From toneman at phil.uu.nl Mon Feb 14 06:16:20 2000
From: toneman at phil.uu.nl (Michiel Toneman)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] SVG
In-Reply-To: <38A369E6.E3845599@geoserve.net>
Message-ID:
On Fri, 11 Feb 2000, J.W. Bizzaro wrote:
> Justin et al.,
>
> Do you know of a widget that can display just SVG graphics? I was conversing
> with the Sodipodi author about this, but it seems he has no plans for making
> one.
>
> Cheers.
> Jeff
>
Have you tried this link? There is a lot of information there.
http://www.levien.com/svg/
This status report may also be of help:
http://www.levien.com/svg/report1.html
Greetings,
Michiel Toneman
--
>From a Sun Microsystems bug report (#4102680):
"Workaround: don't pound on the mouse like a wild monkey."
From mangalam at home.com Mon Feb 14 13:07:07 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca> <38A49D5A.B2E11E1A@home.com> <38A5BC80.A80E04CA@redpoll.pharmacy.ualberta.ca>
Message-ID: <38A8444B.395FED26@home.com>
This just arrived via the DX list: It seems to indicate that CORBA, and
even real time functionality may not be that hard to add to DX.. Basically
you write an "CORBA-input" module and a "CORBA ouput" module and that takes
care of the CORBA comms. DX's internal Data Flow model handles the
analysis internally.
Cheers
harry
gabra@us.ibm.com wrote:
>
> While there is no built-in CORBA interface for DX, there are hooks in DX to
> support asynchronous input. The trick in DX is that modules generally are
> scheduled for execution when their input has changed. Typically, this
> input consists of data arrving on the
> inputs of the modules - the wires connecting a module to its precursors.
> In the case of asynchronous input, what you do is to create a module that
> has two functions. One, a "watcher" procedure, keeps an eye on an input
> stream, and kicks DX to let it know that input has arrived. The other is
> the module itself, which actually reads the input when it runs, creates a
> DX data object from the input, and passes it on down the network.
>
> In the samples, you'll find a prototype in outboard/watchsocket.c. This
> sample module (as you might guess) watches for data input arriving on a
> socket. It opens the socket, and then registers the fd along with the
> "worker" procedure, to the list of fds that DX watches. When input arrives
> on that fd, DX calls the worker procedure, which in turn calls
> DXReadyToRun, passing in the module's identifier. This indicates that
> input has changed on that module, and next time DX executes (immediately,
> if DX is in ExecuteOnChange mode) the module will execute. The module then
> reads the input off the socket, creates an object, and passes it out.
>
> This scenario can be generalized easily. Your module spawns a thread that
> blocks waiting for input in whatever manner is appropriate for the
> communications medium you are using. When input arrives, your thread
> releases and calls DXReadyToRun, just as in the sample.
>
> I hope this makes sense.
>
> Greg
>
> GENE @opendx.watson.ibm.com on 02/12/2000 02:18:04 PM
>
> Please respond to opendx-users@opendx.watson.ibm.com
>
> Sent by: owner-opendx-users@opendx.watson.ibm.com
>
> To: opendx-users@opendx.watson.ibm.com
> cc:
> Subject: Re: [opendx-users] Dx and CORBA
>
> Harry Mangalam wrote:
>
> ...
>
> > Second, is there a way for DX servers to communicate via CORBA to make
> data
> > resources, analyses, and requirements known? It seems that this would be
> > generally useful. I'm trying to use it as the basis of distributed
> > processing of gene expression data and since a lot of our other services
> > are CORBA-based, it would be of interest to us to hear if others have
> tried
> > it or if the DX-gurus could suggest an approach to do this.
>
> ...
>
> Let me add two cents more, and ask if there is an existing real-time
> interface
>
> capability in opendx which would support a streaming data source, such as
> radar observation reports, continuously being reported? Secondly, if the
> notion
> of continuously updating a visualization from real-time data is not
> anethema
> to
> the opendx data model, where in the opendx hierarchy of modules, etc. would
> one look to begin to fashion a "real-time" CORBA IDL-defined interface?
>
> Pardon me if this is more suitable material for the dev group - just trying
> to
>
> latch onto the Mangalam theme above.
>
> Gene Montgomery
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From mangalam at home.com Mon Feb 14 13:27:01 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca> <38A49D5A.B2E11E1A@home.com> <38A5BC80.A80E04CA@redpoll.pharmacy.ualberta.ca> <38A8444B.395FED26@home.com>
Message-ID: <38A848F5.752E68C2@home.com>
And, as if there are not enough choices and docs to read with DX, there's
also vtk (tcl/tk, with python bindings):
http://www.kitware.com/vtk.html
which seems to have a similar approach...
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From mangalam at home.com Mon Feb 14 15:06:47 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002112230.PAA20243@redpoll.pharmacy.ualberta.ca> <38A49D5A.B2E11E1A@home.com> <38A5BC80.A80E04CA@redpoll.pharmacy.ualberta.ca> <38A8444B.395FED26@home.com> <38A848F5.752E68C2@home.com>
Message-ID: <38A86057.1DFC544E@home.com>
Not to make everyone heartily sick of this thread, but it looks like the DX
arch CAN be made CORBA-aware with relatively little (hah!) effort. If so,
that would make it a
viable candidate for MY immediate use, and it sounds like this might be of
wider interest as well.
I need to look at the code mentioned with one of our CORBA programmers to
see how easy it is to in fact do this.
Best
Harry
=====================================
gabra@us.ibm.com wrote:
Right. I'd be interested in hearing about what you come up with. If you
need a hand, let me know.
Greg
>Harry Mangalam @opendx.watson.ibm.com on 02/14/2000
> To: opendx-users@opendx.watson.ibm.com
> cc:
> Subject: Re: [opendx-users] Dx and CORBA
>
> Hi Greg, thanks for the input,
>
> So if I follow you, you (or rather *I*) could write a module that takes
> care of communications with CORBA which would just be another input module
> for DX. Depending on the CORBA services required, any and all data could
> flow in thru this channel and be processed in DX as would any other. This
> module would be responsible for setting the granularity of the data to be
> processed, as it would release execution when a complete data chunk had
> arrived. Real time execution would essentially be no different, except
> that the granularity would typically be quite small.
>
> For output, it would be the same - (simplified), all DX modules that want
> to send data to CORBA services would just be wired to a 'CORBA output'
> module which would then take care of the interchange.
>
> Or no?
>
> Thanks for your input!
> Cheers
> harry
>
> gabra@us.ibm.com wrote:
> >
> > While there is no built-in CORBA interface for DX, there are hooks in DX
> to
> > support asynchronous input. The trick in DX is that modules generally
> are
> > scheduled for execution when their input has changed. Typically, this
> > input consists of data arrving on the
> > inputs of the modules - the wires connecting a module to its precursors.
> > In the case of asynchronous input, what you do is to create a module that
> > has two functions. One, a "watcher" procedure, keeps an eye on an input
> > stream, and kicks DX to let it know that input has arrived. The other is
> > the module itself, which actually reads the input when it runs, creates
> a
> > DX data object from the input, and passes it on down the network.
> >
> > In the samples, you'll find a prototype in outboard/watchsocket.c. This
> > sample module (as you might guess) watches for data input arriving on a
> > socket. It opens the socket, and then registers the fd along with the
> > "worker" procedure, to the list of fds that DX watches. When input
> arrives
> > on that fd, DX calls the worker procedure, which in turn calls
> > DXReadyToRun, passing in the module's identifier. This indicates that
> > input has changed on that module, and next time DX executes (immediately,
> > if DX is in ExecuteOnChange mode) the module will execute. The module
> then
> > reads the input off the socket, creates an object, and passes it out.
> >
> > This scenario can be generalized easily. Your module spawns a thread
> that
> > blocks waiting for input in whatever manner is appropriate for the
> > communications medium you are using. When input arrives, your thread
> > releases and calls DXReadyToRun, just as in the sample.
> >
> > I hope this makes sense.
> >
> > Greg
> >
> > GENE @opendx.watson.ibm.com on 02/12/2000 02:18:04 PM
> --
> Cheers,
> Harry
>
> Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From chapmanb at arches.uga.edu Mon Feb 14 18:03:33 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
Message-ID: <200002142306.SAA90594@archa10.cc.uga.edu>
> Not to make everyone heartily sick of this thread, but it looks like
the DX
> arch CAN be made CORBA-aware with relatively little (hah!) effort.
If so,
> that would make it a
> viable candidate for MY immediate use, and it sounds like this might
be of
> wider interest as well.
>
> I need to look at the code mentioned with one of our CORBA
programmers to
> see how easy it is to in fact do this.
Harry,
This is really great news, and I for one would be really
interested to hear about how things go with your attempts to do this.
Although I don't think all of the applications are of immediate
interest to people on the list (anyone on the list interested in oil
and gas mining? :) I think that a lot of the tools provided in open dx
would be really useful for data mining in general in addition to the
specific programs for imaging etc.
Have you given any thought to trying to integrate your own work
with open dx with Loci? I have been playing around with Fnorb (a
python ORB) a little on my own and recently for the Biopython project,
and if you are interested, I could try and help with getting code for
Loci to support some kind of idl for talking with Loci. IMHO, this
would be of great help to Loci in general (to give it some
additional functionality) and would also be a great chance for you to
help out with Loci development (a highly worthy cause!). I'd be
really interested to hear your thoughts on this, specifically what
kind of things you would need Loci to do to meet with the needs for
your project. Just my 2 cents on the topic...
Brad
From mangalam at home.com Mon Feb 14 19:39:58 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:13 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002142306.SAA90594@archa10.cc.uga.edu>
Message-ID: <38A8A05E.83AA943D@home.com>
Brad Chapman wrote:
>
> > Not to make everyone heartily sick of this thread, but it looks like
> the DX
> > arch CAN be made CORBA-aware with relatively little (hah!) effort.
> If so,
> > that would make it a
> > viable candidate for MY immediate use, and it sounds like this might
> be of
> > wider interest as well.
> >
> > I need to look at the code mentioned with one of our CORBA
> programmers to
> > see how easy it is to in fact do this.
>
> Harry,
> This is really great news, and I for one would be really
> interested to hear about how things go with your attempts to do this.
I'll certainly keep the group informed as to what I'm doing. The project
on which I'm working has precious little slack time built in, but I'll be
using this as an opp to start to learn the actually coding involved in
CORBA. I suspect that the admin will have little tolerance for another new
approach to the infrastructure, unless I can show them an example of how it
works off the bat.
> Although I don't think all of the applications are of immediate
> interest to people on the list (anyone on the list interested in oil
> and gas mining? :) I think that a lot of the tools provided in open dx
> would be really useful for data mining in general in addition to the
> specific programs for imaging etc.
Well, I dunno - all the things you and I mentioned deal with very large
numbers. Look at the popularity of BLAST parsers - why do people write
such things? Because the output is largely meaningless unless it can be
munged into something that poeple can conceptualize better. That's all
that the Viz capabilities from DX is trying to do. I'm helping to write
gene expression database analysis tools that will help people see what
their data means in a larger context. Even in tiny genomes like bacteria,
you have 4.6MB of DNA, ~4300 ORFs, very complex interrelationships on a
gene regulation level, more on a biochemical pathway level. How do you
hope to have people conceptualize those relations? I'm hopingthat by using
the kinds of Viz that DX provides, I can at least make a stab at it. It
WILL be slow and ugly at 1st, but it might work - Incyte has licensed SGI's
Mineset to do this (and sells access at $2M/yr)- I'm hoping to do it ...
considerably cheaper. One of the things that I'm counting on is that the
underlying Viz technology is being handed to me - I don't have to implement
the actual GL code for flinging things around in 3D, or texture-mapping, or
doing transparency,e tc. I just have to format the data correctly and
serve it up to the DX Viz engine as an HDF file (or whatever) via CORBA
(eventually); right now all I have to do is format it as an HDF file (which
in large part 'R' can apparently do for me (we're using the R pkg to do
most of the stats).
> Have you given any thought to trying to integrate your own work
> with open dx with Loci? I have been playing around with Fnorb (a
> python ORB) a little on my own and recently for the Biopython project,
> and if you are interested, I could try and help with getting code for
> Loci to support some kind of idl for talking with Loci.
I can see where this would be very useful. If Loci develops as an
analytical pipeline separate from DX or other such approaches, then this
would allow you to graft on the bits of DX functionality that you need.
Actually, wouldn't this be more or less required to allow Loci to extract
resources from other CORBA-based DB's? Most of the other large DBs are
going this way NCGR's GSDB, EBI's SRS also has a CORBA interface now, I
think..) and it would be the most powerful, if not exactly lightweight way
of going about it.
> IMHO, this
> would be of great help to Loci in general (to give it some
> additional functionality) and would also be a great chance for you to
> help out with Loci development (a highly worthy cause!). I'd be
> really interested to hear your thoughts on this, specifically what
> kind of things you would need Loci to do to meet with the needs for
> your project. Just my 2 cents on the topic...
Sure - that's why I posted here. The whole project is Loci-amenable or
even (for me) a Loci replacement. I'm not trying to denigrate the Loci
project - it's what got me thinking about this approach, and I've picked up
some great ideas and pointers from the traffic here (in fact, this list is
one of my favorite for user-filtered pointers - if someone posts an
'interesting URL', I'll usually try to track it down; it's almost
guaranteed to be useful) , but we (NCGR) need something that works right
now and even tho DX was born years ago (like unix), it's been
well-thought-out and debugged (like unix) and may, with only a little
meddling at an external interface, support a tremendous amount of the
functionality that we need. And I personally would rather design nifty
analytical tools than infrastructure.
Don't forget to read that URL that Gary posted:
http://www.cs.wustl.edu/~schmidt/CACM-lessons.html
Best
Harry
>
> Brad
>
> _______________________________________________
> pipet-devel maillist - pipet-devel@bioinformatics.org
> http://bioinformatics.org/mailman/listinfo/pipet-devel
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From tim at xoom.com Mon Feb 14 20:12:34 2000
From: tim at xoom.com (Tim Triche)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
In-Reply-To: <38A8A05E.83AA943D@home.com>; from mangalam@home.com on Mon, Feb 14, 2000 at 04:39:58PM -0800
References: <200002142306.SAA90594@archa10.cc.uga.edu> <38A8A05E.83AA943D@home.com>
Message-ID: <20000214171234.A20806@xoom.com>
Just a note, that while DX is a damn nifty program and akin to what some of
the NCGR folks were trying to do a while back, it is a complex beast with many
quirks. Be sure to read the opendx-users list and pay attention to what people
like Greg Abrams and Chris Pelkie have to say... they know what they're doing.
Also worth a look is the VTK package, http://www.kitware.com/vtk.html -- it is
a set of C++ classes rather than an integrated app like DX, but sometimes that's
even better. And sometimes it's not...
One thing that DX has which VTK doesn't is a lot of Motif dependencies for the
VPE. But perhaps Java Explorer is the answer to that problem. In any event,
the DX people are way cool and their code is at least comprehensible (like the
VTK code, but unlike some code I've seen) so I'm sure you'll find a lot of ways
to leverage their work.
Best of luck. I really wish I had enough time to work on cool stuff like this
nowadays. Money is nice but I miss the challenge of nasty projects like yours.
Got to go back to school one of these days.
--
"This is a job for BOB VIOLENCE and SCUM, the INCREDIBLY STUPID MUTANT DOG."
-- Bob Violence
From mangalam at home.com Mon Feb 14 23:51:54 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002142306.SAA90594@archa10.cc.uga.edu> <38A8A05E.83AA943D@home.com> <20000214171234.A20806@xoom.com>
Message-ID: <38A8DB6A.2363CEED@home.com>
Tim Triche wrote:
>
> Just a note, that while DX is a damn nifty program and akin to what some of
> the NCGR folks were trying to do a while back, it is a complex beast with many
> quirks. Be sure to read the opendx-users list and pay attention to what people
> like Greg Abrams and Chris Pelkie have to say... they know what they're doing.
Thanks Tim, I've been signed up for several months - this is where I got a
lot of my info about DX.
> Also worth a look is the VTK package, http://www.kitware.com/vtk.html -- it is
> a set of C++ classes rather than an integrated app like DX, but sometimes that's
> even better. And sometimes it's not...
I saw this just recently - do you have more experience with vtk? I have
none at all, but one thing that does appeal to me is the visual programming
paradigm of DX. That translates into programability not only for
developers, but especially for users (even if they might have to be
relatively attuned users).
> One thing that DX has which VTK doesn't is a lot of Motif dependencies for the
> VPE.
But it's worth noting that DX now compiles and seems to run OK w/ Lesstif.
> But perhaps Java Explorer is the answer to that problem.
But then you have all those Java dependencies ;)....
> In any event,
> the DX people are way cool and their code is at least comprehensible (like the
> VTK code, but unlike some code I've seen) so I'm sure you'll find a lot of ways
> to leverage their work.
> Best of luck. I really wish I had enough time to work on cool stuff like this
> nowadays. Money is nice but I miss the challenge of nasty projects like yours.
'Nasty' is sometimes a very accurate word...
thanks for your words of warning - there's no thing as a free lunch, but
sometimes you find something that will pay for the meatloaf so you can
spend more on dessert.. But you do have to be careful that the meatloaf
doesn't tie you to tapioca pudding. Or something..
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From chapmanb at arches.uga.edu Tue Feb 15 00:35:49 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
Message-ID: <200002150539.AAA14904@archa12.cc.uga.edu>
> I'm helping to write
> gene expression database analysis tools that will help people see
what
> their data means in a larger context. Even in tiny genomes like
bacteria,
> you have 4.6MB of DNA, ~4300 ORFs, very complex interrelationships
on a
> gene regulation level, more on a biochemical pathway level. How do
you
> hope to have people conceptualize those relations?
If you're doing gene expression stuff, have you checked out the code
available from biojava (http://www.biojava.org with API docs at
http://www.sanger.ac.uk/Users/td2/biojava-docs/)? I know that they
have some Suppor Vector Machine (SVM) code, which seems to be the most
current "popular" method to cluster expression data. The paper in PNAS
that I read on this also has a SVM implementation
(http://www.cse.ucsc.edu/research/compbio/genex/genex.html), so they
might be interesting to compare.
> but we (NCGR) need something that works right
> now and even tho DX was born years ago (like unix), it's been
> well-thought-out and debugged (like unix) and may, with only a little
> meddling at an external interface, support a tremendous amount of the
> functionality that we need. And I personally would rather design
nifty
> analytical tools than infrastructure.
Makes sense, especially when you're on a limited time frame. I'll
be interested to hear how it works out.
Brad
From mangalam at home.com Tue Feb 15 12:21:34 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] Open DX as a loci skeleton?
References: <200002150539.AAA14904@archa12.cc.uga.edu>
Message-ID: <38A98B1E.C9C88F59@home.com>
thanks Brad!
I had heard about a biojava group, but I wasn't aware that they existed as
a formal entity yet. And now I'm a subscriber...
And I'm just now reading thru the PNAS paper that you mentioned.
See what I mean about this list providing the most-useful URLs? :)
Best
hjm
Brad Chapman wrote:
>
> > I'm helping to write
> > gene expression database analysis tools that will help people see
> what
> > their data means in a larger context. Even in tiny genomes like
> bacteria,
> > you have 4.6MB of DNA, ~4300 ORFs, very complex interrelationships
> on a
> > gene regulation level, more on a biochemical pathway level. How do
> you
> > hope to have people conceptualize those relations?
>
> If you're doing gene expression stuff, have you checked out the code
> available from biojava (http://www.biojava.org with API docs at
> http://www.sanger.ac.uk/Users/td2/biojava-docs/)? I know that they
> have some Suppor Vector Machine (SVM) code, which seems to be the most
> current "popular" method to cluster expression data. The paper in PNAS
> that I read on this also has a SVM implementation
> (http://www.cse.ucsc.edu/research/compbio/genex/genex.html), so they
> might be interesting to compare.
>
> > but we (NCGR) need something that works right
> > now and even tho DX was born years ago (like unix), it's been
> > well-thought-out and debugged (like unix) and may, with only a little
> > meddling at an external interface, support a tremendous amount of the
> > functionality that we need. And I personally would rather design
> nifty
> > analytical tools than infrastructure.
>
> Makes sense, especially when you're on a limited time frame. I'll
> be interested to hear how it works out.
>
> Brad
>
> _______________________________________________
> pipet-devel maillist - pipet-devel@bioinformatics.org
> http://bioinformatics.org/mailman/listinfo/pipet-devel
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From bizzaro at geoserve.net Wed Feb 16 06:22:10 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] The Mighty Fine (Command) Line - Beating a Dead Horse
Message-ID: <38AA8862.301F5A47@geoserve.net>
Locians,
This is interesting and somewhat relevant:
http://www.linuxplanet.com/linuxplanet/opinions/1505/2/
Jeff
From bizzaro at geoserve.net Wed Feb 16 06:24:02 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] The Mighty Fine (Command) Line - Beating a Dead Horse
References: <38AA8862.301F5A47@geoserve.net>
Message-ID: <38AA88D2.A9EE4564@geoserve.net>
"J.W. Bizzaro" wrote:
>
> http://www.linuxplanet.com/linuxplanet/opinions/1505/2/
Correction: Page 1 is at
http://www.linuxplanet.com/linuxplanet/opinions/1505/1/
Jeff
From bizzaro at geoserve.net Thu Feb 17 02:04:08 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] python vs. perl
Message-ID: <38AB9D68.6080BCAC@geoserve.net>
There is an interesting article and discussion about this scripting language
war. Here is a comment posted by a (former) Perl programmer:
---------------------------------------
It's sort of like a really clean C++ with the convenience of Perl.
I would HIGHLY recommend Python as being something you need to learn and start
using! I mean, Perl is good for hacking stuff together because you know how to
do it in Perl. Even Bash is good for that.. But Python really gives you a good
feeling that you are architecting something that is made to work, made to
last, and made to be maintainable. And Python is extremely good for quick
Perl-ish hack jobs.
Maybe Perl (in reference to an above post) is for artists, but I think Python
is for designers. Know which one you are, before you do anything else.
----------------------------------------
http://slashdot.org/article.pl?sid=00/02/16/1729227&mode=flat
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From birney at ebi.ac.uk Thu Feb 17 12:42:30 2000
From: birney at ebi.ac.uk (Ewan Birney)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] Re: [BioPython] python vs. perl
In-Reply-To: <38AB9D68.6080BCAC@geoserve.net>
Message-ID:
On Thu, 17 Feb 2000, J.W. Bizzaro wrote:
> There is an interesting article and discussion about this scripting language
> war. Here is a comment posted by a (former) Perl programmer:
>
> ---------------------------------------
> It's sort of like a really clean C++ with the convenience of Perl.
>
> I would HIGHLY recommend Python as being something you need to learn and start
> using! I mean, Perl is good for hacking stuff together because you know how to
> do it in Perl. Even Bash is good for that.. But Python really gives you a good
> feeling that you are architecting something that is made to work, made to
> last, and made to be maintainable. And Python is extremely good for quick
> Perl-ish hack jobs.
I agree completely ;) (and I am coordinating bioperl!). But
Perl is ultimately portable
has an incredible set of extensions - CPAN
and the killer
95% of bioinformaticians use Perl
But I honestly believe the future is jpython/java objects on the server,
python/jpython/possibly perl on the scripting/driving side. Hence the
biocorba stuff.
>
> Maybe Perl (in reference to an above post) is for artists, but I think Python
> is for designers. Know which one you are, before you do anything else.
> ----------------------------------------
>
> http://slashdot.org/article.pl?sid=00/02/16/1729227&mode=flat
>
> Cheers.
> Jeff
> --
> +----------------------------------+
> | J.W. Bizzaro |
> | |
> | http://bioinformatics.org/~jeff/ |
> | |
> | BIOINFORMATICS.ORG |
> | The Open Lab |
> | |
> | http://bioinformatics.org/ |
> +----------------------------------+
>
> _______________________________________________
> BioPython mailing list - BioPython@biopython.org
> http://biopython.org/mailman/listinfo/biopython
>
From bizzaro at geoserve.net Thu Feb 17 15:43:49 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] Eazel
Message-ID: <38AC5D85.1F99B8B8@geoserve.net>
http://www.eazel.com/
I wonder what they're up to. They are supposedly extending Gnome to make it
simple to use. And it appears they have something to do with Havoc's Nautilus
file manager, but Havoc doesn't work there. Hmmmm.
Jeff
From bizzaro at geoserve.net Fri Feb 18 09:28:30 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] Inventing the Lisa Interface
Message-ID: <38AD570E.31D5479D@geoserve.net>
For those GUI fanatics among us (including myself), here is a site that covers
the development of the Apple Lisa GUI and desktop:
http://home.san.rr.com/deans/lisagui.html
Nearly every GUI and desktop in use today can trace its ancestry back to the
Lisa, for better or worse. (BTW, I believe Loci's workspace is not a direct
descendant of Lisa's desktop. We're rethinking quite a few things.)
The screenshots page of prototypes is very interesting. Note that the first
prototype was made on an Apple II in 1979 (!)
http://home.san.rr.com/deans/prototypes.html
Cheers.
Jeff
From bizzaro at geoserve.net Fri Feb 18 11:36:18 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
Message-ID: <38AD7502.C4603E62@geoserve.net>
Here is my personal TODO:
J.W. Bizzaro; TODO 20000218
----------------------------------
1. Split gi workspace up into many more modules to keep things easy to
manage.
2. Make windowlets resizable via dragging frame.
3. Add multiple locus selection to gi workspace. SHIFT-button1 and
CTRL-button1 will
do this.
4. Work on locus deletion. Brad started this. There should be 2 types: (1)
complete
removal and (2) change to a composite locus, which uses (1).
5. Work on locus disconnection via pop-up menu over connector.
6. Add windowlets to locus connectors. These will give connector
status/info.
7. Pop-up menu needs to reflect the item selected: locus, connector or
workspace.
8. For the time being, I want locus addition to take place via DnD with
containers. The
'Add' pop-up submenu in the end will be for adding MIME and connection
type-compatible
loci to other loci. We're a long way from doing that, so I want to remove
it (Brad).
9. We need a locus clipboard for doing copy/cut/paste of loci. I think this
should be
a subtype of the composite locus type and able to be placed on the
workspace.
10. Loci needs to start up with a few loci already on the workspace:
containers.
11. Establish communication pipe with middleware. NOTE that the gi workspace
is a 'dumb'
front-end to the middleware, and that some of what has been hard-coded
into the
gi workspace (by Brad) needs to be abstracted out to the middleware.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 18 11:44:35 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
References: <38AD7502.C4603E62@geoserve.net>
Message-ID: <38AD76F3.334FBE09@geoserve.net>
Okay, this might be a little easier to read:
J.W. Bizzaro; TODO 20000218
----------------------------------
1. Split gi workspace up into many more modules to keep things easy to manage.
2. Make windowlets resizable via dragging frame.
3. Add multiple locus selection to gi workspace. SHIFT-button1 and
CTRL-button1 will do this.
4. Work on locus deletion. Brad started this. There should be 2 types:
(1) complete removal and (2) change to a composite locus, which uses (1).
5. Work on locus disconnection via pop-up menu over connector.
6. Add windowlets to locus connectors. These will give connector status/info.
7. Pop-up menu needs to reflect the item selected: locus, connector or
workspace.
8. For the time being, I want locus addition to take place via DnD with
containers. The 'Add' pop-up submenu in the end will be for adding MIME
and connection type-compatible loci to other loci. We're a long way from
doing that, so I want to remove it (Brad).
9. We need a locus clipboard for doing copy/cut/paste of loci. I think this
should be a subtype of the composite locus type and able to be placed on
the workspace.
10. Loci needs to start up with a few loci already on the workspace:
containers.
11. Establish communication pipe with middleware. NOTE that the gi workspace
is a 'dumb' front-end to the middleware, and that some of what has been
hard-coded into the gi workspace (by Brad) needs to be abstracted out to
the middleware.
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From chapmanb at arches.uga.edu Fri Feb 18 16:27:08 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
In-Reply-To: <38AD76F3.334FBE09@geoserve.net>
Message-ID:
Jeff;
Thanks for getting this together! I *really* hope to be back at
programming soon, as I'm going to be ill if I spend any more time staring
at Microsoft Word and typing about cactus...
Comments below:
> J.W. Bizzaro; TODO 20000218
> ----------------------------------
> 1. Split gi workspace up into many more modules to keep things easy to manage.
This is a really good idea. I was thinking it might be helpful to add a
new connector/dot class (which will probably be needed once dots get more
complicated). Then we could move the event stuff for dots/lines to this
class and also move the locus event stuff to the locus class.
> 2. Make windowlets resizable via dragging frame.
Do we still need this if we have "automatically scrolling windows"?
> 3. Add multiple locus selection to gi workspace. SHIFT-button1 and
> CTRL-button1 will do this.
This would be really helpful--they we could start setting up simple piping
stuff (ie. a document to a viewer).
> 4. Work on locus deletion. Brad started this. There should be 2 types:
> (1) complete removal and (2) change to a composite locus, which uses (1).
> 5. Work on locus disconnection via pop-up menu over connector.
Let me know if the stuff I did makes sense when you start looking at this.
I might be able to make it cleaner/more usable if there are problems.
> 6. Add windowlets to locus connectors. These will give connector status/info.
> 7. Pop-up menu needs to reflect the item selected: locus, connector or
> workspace.
Don't forget about my button 3 "fix." We'll need to think of something new
to do for this if you want to start adding more functionality to the
pop-up menu.
> 8. For the time being, I want locus addition to take place via DnD with
> containers. The 'Add' pop-up submenu in the end will be for adding MIME
> and connection type-compatible loci to other loci. We're a long way from
> doing that, so I want to remove it (Brad).
Okay, that shouldn't be too big a problem for most stuff since we have
drag and drop working.
However, what about database stuff--right now I'm connecting through a
blank added container. How would this work under the new system?
> 9. We need a locus clipboard for doing copy/cut/paste of loci. I think this
> should be a subtype of the composite locus type and able to be placed on
> the workspace.
Do you have a plan for keeping these type of containers out of the way?
Have a toolbar contiainer of useful loci? You could drag them out of the
toolbar to add stuff to them, but when they get deleted from the
workspace, they go right back to the toolbar. Is this an idea?
> 10. Loci needs to start up with a few loci already on the workspace:
> containers.
Maybe this would be how to deal with the database problem I mentioned
earlier?
> 11. Establish communication pipe with middleware. NOTE that the gi workspace
> is a 'dumb' front-end to the middleware, and that some of what has been
> hard-coded into the gi workspace (by Brad) needs to be abstracted out to
> the middleware.
You are absolutely right about this. The middleware and frontware XML
stuff is especially tangled. I've started to untangle it, and this what
I'll be working on asap. I think I have a better model for how this can
work and how I can extract things to be nicer. A lot of that ugliness are
my kludges to make things work when I didn't really have a view about how
all the code would look in the long term. I see some things a little
clearer now, and I definately think fixing this up should be a priority
for me so that we'll have less code breaking in the future.
Thanks again for the ToDo list!
Brad
From gvd at redpoll.pharmacy.ualberta.ca Fri Feb 18 21:32:00 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] G Van Domselaar TODO 20000218
Message-ID: <38AE00A0.66BBD84C@redpoll.pharmacy.ualberta.ca>
Just so you locians don't think I'm totally slacking...
1. Convert the SourceForge project development environment into a
bioinformatics.org
project environment. This is gonna be a couple of weeks at least.
There's a lot
of nifty code to be modified for our TOL. You can monitor the
progress by pointing
your browsers to alpha.bioinformatics.org. Any suggestions on
style, structure, content
etc. etc. are welcome!
2. Migrate the existing TOL projects into the new environment. It
should be sweet!
3. Harry's piqued my interest in the OpenDX/ ACE environments. I'd
like to study their architectures
and hopefully apply what I learn to help design Loci's
communications brokering engine.
4. Read 'Inside OLE', 'GNOME/GTk+ Application Development', 'GNOME &
CORBA'
5. Start writing some intelligent documentation.
Regards,
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From bizzaro at geoserve.net Fri Feb 18 23:38:46 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] G Van Domselaar TODO 20000218
References: <38AE00A0.66BBD84C@redpoll.pharmacy.ualberta.ca>
Message-ID: <38AE1E56.20C40DD2@geoserve.net>
Gary Van Domselaar wrote:
>
> Just so you locians don't think I'm totally slacking...
Slacker ;-)
> 4. Read 'Inside OLE', 'GNOME/GTk+ Application Development', 'GNOME &
> CORBA'
Is there a book on GNOME & CORBA now? Or are you referring to online docs?
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sat Feb 19 00:28:57 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
References:
Message-ID: <38AE2A19.C61CDF9A@geoserve.net>
Brad Chapman wrote:
>
> > 1. Split gi workspace up into many more modules to keep things easy to manage.
>
> This is a really good idea. I was thinking it might be helpful to add a
> new connector/dot class (which will probably be needed once dots get more
> complicated). Then we could move the event stuff for dots/lines to this
> class and also move the locus event stuff to the locus class.
I was thinking about the event handlers being in their own modules. But, do
you think splitting up such highly accessed methods (e.g., whenever a locus
gets dragged) will slow things down? This is a question I have about Python
operation. Maybe someone here knows the answer to that.
> > 2. Make windowlets resizable via dragging frame.
>
> Do we still need this if we have "automatically scrolling windows"?
Yeah, windowlets should have much of the functionality of full-fledged X
windows. This is especially useful for composite/sub-workspace windowlets,
where you may need lots of room to work within a windowlet. We/I will be
adding some 'window manager' features to the workspace.
> > 3. Add multiple locus selection to gi workspace. SHIFT-button1 and
> > CTRL-button1 will do this.
>
> This would be really helpful--they we could start setting up simple piping
> stuff (ie. a document to a viewer)
It is certainly needed to make composites: Select the loci to be composited,
choose 'composite' from pop-up menu, and ZAPP-O, one locus takes the place of
many.
> > 4. Work on locus deletion. Brad started this. There should be 2 types:
> > (1) complete removal and (2) change to a composite locus, which uses (1).
> > 5. Work on locus disconnection via pop-up menu over connector.
>
> Let me know if the stuff I did makes sense when you start looking at this.
> I might be able to make it cleaner/more usable if there are problems.
I was planning on making a method that is the inverse of the connect_loci
method. I'll go check out what you did.
> > 6. Add windowlets to locus connectors. These will give connector status/info.
> > 7. Pop-up menu needs to reflect the item selected: locus, connector or
> > workspace.
>
> Don't forget about my button 3 "fix." We'll need to think of something new
> to do for this if you want to start adding more functionality to the
> pop-up menu.
Right, I need to add that to my TODO list.
> > 8. For the time being, I want locus addition to take place via DnD with
> > containers. The 'Add' pop-up submenu in the end will be for adding MIME
> > and connection type-compatible loci to other loci. We're a long way from
> > doing that, so I want to remove it (Brad).
>
> Okay, that shouldn't be too big a problem for most stuff since we have
> drag and drop working.
> However, what about database stuff--right now I'm connecting through a
> blank added container. How would this work under the new system?
Can we put a blank database container in one of the main
containers/directories?
$LOCIHOME/back/private/container/
Blank containers are wrappers with an XML description (like all loci), right?
Then we can put the wrapper in the container/directory.
(I know you argued for a different way to manage private loci. I have to get
back to you on that.)
> > 9. We need a locus clipboard for doing copy/cut/paste of loci. I think this
> > should be a subtype of the composite locus type and able to be placed on
> > the workspace.
>
> Do you have a plan for keeping these type of containers out of the way?
> Have a toolbar contiainer of useful loci? You could drag them out of the
> toolbar to add stuff to them, but when they get deleted from the
> workspace, they go right back to the toolbar. Is this an idea?
I was thinking the clipboard should be a 'composite' type locus rather than a
'container' type locus. This is because composites preserve connectivity,
which should be preserved during copy/cut/paste. Trash loci should also be
composite type for the same reason. But then again, if you composite the stuff
that is to be trashed/copy/cut/pasted, you can then put it in a container.
As for keeping 'permanent' loci 'out of the way', How about having a 'hide
locus' option that makes a locus invisible although not deleted?
> > 10. Loci needs to start up with a few loci already on the workspace:
> > containers.
>
> Maybe this would be how to deal with the database problem I mentioned
> earlier?
Well, I think we can have a permanent container representing a Loci directory
(as mentioned above), and a blank database container can be pulled out.
> > 11. Establish communication pipe with middleware. NOTE that the gi workspace
> > is a 'dumb' front-end to the middleware, and that some of what has been
> > hard-coded into the gi workspace (by Brad) needs to be abstracted out to
> > the middleware.
>
> You are absolutely right about this. The middleware and frontware XML
> stuff is especially tangled. I've started to untangle it, and this what
> I'll be working on asap. I think I have a better model for how this can
> work and how I can extract things to be nicer. A lot of that ugliness are
> my kludges to make things work when I didn't really have a view about how
> all the code would look in the long term. I see some things a little
> clearer now, and I definately think fixing this up should be a priority
> for me so that we'll have less code breaking in the future.
What may be confusing, and I'm not sure how much I wrote about this to you, is
that the front-end(s) and the middleware will communicate by sending XML tags
back and forth. And the tags are commands. Here's an example:
gi requests selection of locus
middle approves
...
The middleware will have to echo back an approval for the front-end to proceed.
This will be a 'dialog' that occurs through a pipe (Gary mentioned that this
might occur via HTTP). This dialog can then be saved. Recall early
discussions about an 'electronic laboratory notebook'. Well, saving the dialog
allows us to do that. Heck, we can even 'play back' the entire work session,
with the workspace reenacting for the user what was done. Cooooool.
Plus, abstracting the middlware from the front-end allows us to swap something
else for a front-end. Remember the natural language interface (NLI)? Imagine
how that would work in place of gi:
user> Select the locus 387hwj7843
loci> Okay. Locus 387hwj7843 selected.
The XML is always hidden from the user.
Gary and I developed this approach together. If you have more questions,
perhaps Gary can join in on the conversion ;-)
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sat Feb 19 00:35:51 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] new propaganda tiles
Message-ID: <38AE2BB7.211AD7B8@geoserve.net>
Volume 14, Rebirth:
http://propaganda.system12.com/Catalog/Vol14/catalog.html
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sat Feb 19 00:41:30 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] new propaganda tiles
References: <38AE2BB7.211AD7B8@geoserve.net>
Message-ID: <38AE2D0A.22A83889@geoserve.net>
"J.W. Bizzaro" wrote:
>
> Volume 14, Rebirth:
>
> http://propaganda.system12.com/Catalog/Vol14/catalog.html
Sorry, this was meant for the Web site admin list (groovy backgrounds and all).
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Sat Feb 19 12:21:20 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] G Van Domselaar TODO 20000218
References: <38AE00A0.66BBD84C@redpoll.pharmacy.ualberta.ca> <38AE1E56.20C40DD2@geoserve.net>
Message-ID: <38AED110.3F847CF@redpoll.pharmacy.ualberta.ca>
"J.W. Bizzaro" wrote:
>
>
> Is there a book on GNOME & CORBA now? Or are you referring to online docs?
Yeah, the online docs are worth reading a couple of times. If anyone
can recommend a good book on CORBA for me, I'd appreciate that as well.
Brad? You seem to be doing pretty well; I see your posts all over
biopython ;-)
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From gvd at redpoll.pharmacy.ualberta.ca Sat Feb 19 12:36:20 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
References: <38AE2A19.C61CDF9A@geoserve.net>
Message-ID: <38AED494.C545FC5C@redpoll.pharmacy.ualberta.ca>
"J.W. Bizzaro" wrote:
>
> Brad Chapman wrote:
> >
> > > 1. Split gi workspace up into many more modules to keep things easy to manage.
> >
> > This is a really good idea. I was thinking it might be helpful to add a
> > new connector/dot class (which will probably be needed once dots get more
> > complicated). Then we could move the event stuff for dots/lines to this
> > class and also move the locus event stuff to the locus class.
>
> I was thinking about the event handlers being in their own modules. But, do
> you think splitting up such highly accessed methods (e.g., whenever a locus
> gets dragged) will slow things down? This is a question I have about Python
> operation. Maybe someone here knows the answer to that.
>
> > > 2. Make windowlets resizable via dragging frame.
> >
> > Do we still need this if we have "automatically scrolling windows"?
>
> Yeah, windowlets should have much of the functionality of full-fledged X
> windows. This is especially useful for composite/sub-workspace windowlets,
> where you may need lots of room to work within a windowlet. We/I will be
> adding some 'window manager' features to the workspace.
>
> > > 3. Add multiple locus selection to gi workspace. SHIFT-button1 and
> > > CTRL-button1 will do this.
> >
> > This would be really helpful--they we could start setting up simple piping
> > stuff (ie. a document to a viewer)
>
> It is certainly needed to make composites: Select the loci to be composited,
> choose 'composite' from pop-up menu, and ZAPP-O, one locus takes the place of
> many.
>
> > > 4. Work on locus deletion. Brad started this. There should be 2 types:
> > > (1) complete removal and (2) change to a composite locus, which uses (1).
> > > 5. Work on locus disconnection via pop-up menu over connector.
> >
> > Let me know if the stuff I did makes sense when you start looking at this.
> > I might be able to make it cleaner/more usable if there are problems.
>
> I was planning on making a method that is the inverse of the connect_loci
> method. I'll go check out what you did.
>
> > > 6. Add windowlets to locus connectors. These will give connector status/info.
> > > 7. Pop-up menu needs to reflect the item selected: locus, connector or
> > > workspace.
> >
> > Don't forget about my button 3 "fix." We'll need to think of something new
> > to do for this if you want to start adding more functionality to the
> > pop-up menu.
>
> Right, I need to add that to my TODO list.
>
> > > 8. For the time being, I want locus addition to take place via DnD with
> > > containers. The 'Add' pop-up submenu in the end will be for adding MIME
> > > and connection type-compatible loci to other loci. We're a long way from
> > > doing that, so I want to remove it (Brad).
> >
> > Okay, that shouldn't be too big a problem for most stuff since we have
> > drag and drop working.
> > However, what about database stuff--right now I'm connecting through a
> > blank added container. How would this work under the new system?
>
> Can we put a blank database container in one of the main
> containers/directories?
>
> $LOCIHOME/back/private/container/
>
> Blank containers are wrappers with an XML description (like all loci), right?
> Then we can put the wrapper in the container/directory.
>
> (I know you argued for a different way to manage private loci. I have to get
> back to you on that.)
>
> > > 9. We need a locus clipboard for doing copy/cut/paste of loci. I think this
> > > should be a subtype of the composite locus type and able to be placed on
> > > the workspace.
> >
> > Do you have a plan for keeping these type of containers out of the way?
> > Have a toolbar contiainer of useful loci? You could drag them out of the
> > toolbar to add stuff to them, but when they get deleted from the
> > workspace, they go right back to the toolbar. Is this an idea?
>
> I was thinking the clipboard should be a 'composite' type locus rather than a
> 'container' type locus. This is because composites preserve connectivity,
> which should be preserved during copy/cut/paste. Trash loci should also be
> composite type for the same reason. But then again, if you composite the stuff
> that is to be trashed/copy/cut/pasted, you can then put it in a container.
>
> As for keeping 'permanent' loci 'out of the way', How about having a 'hide
> locus' option that makes a locus invisible although not deleted?
>
> > > 10. Loci needs to start up with a few loci already on the workspace:
> > > containers.
> >
> > Maybe this would be how to deal with the database problem I mentioned
> > earlier?
>
> Well, I think we can have a permanent container representing a Loci directory
> (as mentioned above), and a blank database container can be pulled out.
>
> > > 11. Establish communication pipe with middleware. NOTE that the gi workspace
> > > is a 'dumb' front-end to the middleware, and that some of what has been
> > > hard-coded into the gi workspace (by Brad) needs to be abstracted out to
> > > the middleware.
> >
> > You are absolutely right about this. The middleware and frontware XML
> > stuff is especially tangled. I've started to untangle it, and this what
> > I'll be working on asap. I think I have a better model for how this can
> > work and how I can extract things to be nicer. A lot of that ugliness are
> > my kludges to make things work when I didn't really have a view about how
> > all the code would look in the long term. I see some things a little
> > clearer now, and I definately think fixing this up should be a priority
> > for me so that we'll have less code breaking in the future.
>
> What may be confusing, and I'm not sure how much I wrote about this to you, is
> that the front-end(s) and the middleware will communicate by sending XML tags
> back and forth. And the tags are commands. Here's an example:
>
> gi requests selection of locus
> middle approves
> ...
>
> The middleware will have to echo back an approval for the front-end to proceed.
>
> This will be a 'dialog' that occurs through a pipe (Gary mentioned that this
> might occur via HTTP).
HTTP works well with xml and would give us the hook into an
xml-compliant web-browser interface if and when this aspect of loci
comes about.
> Gary and I developed this approach together. If you have more questions,
> perhaps Gary can join in on the conversion ;-)
OpenDX also uses this approach. Actually, Brad, did you ever receive
those rough Loci architecture drafts that Jeff and I hacked together? I
wouldn't mind making a wp doc from those and posting it to the group,
once it gets the stamp of approval. Maybe I should add _that_ to _my_
TODO list.
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From gvd at redpoll.pharmacy.ualberta.ca Sat Feb 19 12:38:22 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] new propaganda tiles
References: <38AE2BB7.211AD7B8@geoserve.net>
Message-ID: <38AED50E.A01241ED@redpoll.pharmacy.ualberta.ca>
"J.W. Bizzaro" wrote:
>
> Volume 14, Rebirth:
>
> http://propaganda.system12.com/Catalog/Vol14/catalog.html
Cool, btw I think there's a way to resize mutliple images using
imagemagick (convert --help). If not, I've got my gimp set up for perl
scripting as a backup ;-)
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From gvd at redpoll.pharmacy.ualberta.ca Sat Feb 19 12:45:16 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
References: <38AE2A19.C61CDF9A@geoserve.net> <38AED494.C545FC5C@redpoll.pharmacy.ualberta.ca>
Message-ID: <38AED6AC.5C14EC89@redpoll.pharmacy.ualberta.ca>
Gary Van Domselaar wrote:
Whoops, here's the reader's digest version ;-)
> > What may be confusing, and I'm not sure how much I wrote about this to you, is
> > that the front-end(s) and the middleware will communicate by sending XML tags
> > back and forth. And the tags are commands. Here's an example:
> >
> > gi requests selection of locus
> > middle approves
> > ...
> >
> > The middleware will have to echo back an approval for the front-end to proceed.
> >
> > This will be a 'dialog' that occurs through a pipe (Gary mentioned that this
> > might occur via HTTP).
>
> HTTP works well with xml and would give us the hook into an
> xml-compliant web-browser interface if and when this aspect of loci
> comes about.
>
> > Gary and I developed this approach together. If you have more questions,
> > perhaps Gary can join in on the conversion ;-)
>
> OpenDX also uses this approach. Actually, Brad, did you ever receive
> those rough Loci architecture drafts that Jeff and I hacked together? I
> wouldn't mind making a wp doc from those and posting it to the group,
> once it gets the stamp of approval. Maybe I should add _that_ to _my_
> TODO list.
>
> g.
> --
> Gary Van Domselaar
> gary@bioinformatics.org
> http://www.bioinformatics.org/~gary
> ----------------------------------------------------
> bioinformatics.org: The Open Lab
> http://www.bioinformatics.org/
>
From dlapointe at mediaone.net Sat Feb 19 13:35:48 2000
From: dlapointe at mediaone.net (David Lapointe)
Date: Fri Feb 10 19:19:14 2006
Subject: [Pipet Devel] ANT - a java based buikd tool
In-Reply-To: <38AED6AC.5C14EC89@redpoll.pharmacy.ualberta.ca>
References: <38AED494.C545FC5C@redpoll.pharmacy.ualberta.ca> <38AED6AC.5C14EC89@redpoll.pharmacy.ualberta.ca>
Message-ID: <00021913420700.00533@gnomen>
Locians,
A subproject of Jakarta is ANT which is a java based build tool. Make is the standard build tool, but is very dependant
on OS and platform. ANT strives for platform independance.
http://jakarta.apache.org/ant/index.html
"Ant is different. Instead a model where it is extended with shell based commands, it is extended using
Java classes. Instead of writing shell commands, the configuration files are XML based calling out a
target tree where various tasks get executed. Each task is run by an object which implements a
particular Task interface. "
--
.david
David Lapointe
If you're not living on the edge, you're taking up too much space.
From gvd at redpoll.pharmacy.ualberta.ca Sat Feb 19 20:50:51 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] Python/GNOME tutorial
Message-ID: <200002200150.SAA02852@redpoll.pharmacy.ualberta.ca>
Found this puppy on the GNOME web site
http://laguna.fmedic.unam.mx/~daniel/pygtutorial/
Posted by Miguel de Icaza:
A tutorial on using Python to develop GNOME compliant applications has
been written by Daniel. Very useful, considering that many people are using
Python/GNOME as their Rapid Application Development platform these days.
enjoy!
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From bizzaro at geoserve.net Mon Feb 21 09:11:56 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] more on Eazel
Message-ID: <38B147AC.EAEAAAEE@geoserve.net>
Here is an article at the NY Times about Eazel. It was founded last fall by 4
of the original core Mac OS developers of the early 1980's. One of these guys
even went on head Steve Job's NeXT OS development.
Excerpt:
"This summer, Eazel plans to begin offering a free user interface -- an
icon-based software control system that can be downloaded from the Internet..."
Should we (Loci) be concerned? It's based on Gnome too.
http://www.nytimes.com/library/tech/00/02/biztech/articles/21eaze.html
(free account required)
Cheers.
Jeff
From chapmanb at arches.uga.edu Mon Feb 21 20:57:09 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
Message-ID: <200002220200.VAA106850@archa10.cc.uga.edu>
> I was thinking about the event handlers being in their own modules.
But, do
> you think splitting up such highly accessed methods (e.g., whenever
a locus
> gets dragged) will slow things down? This is a question I have
about Python
> operation. Maybe someone here knows the answer to that.
Not me! I don't really know the internal methods by which
interclass communication occurs, but I guess I've never read anything
about splitting things into classes making them slower, so I would
agree that it's a good idea to try.
>> Let me know if the stuff I did makes sense when you start looking
at this.
>> I might be able to make it cleaner/more usable if there are
problems.
>
> I was planning on making a method that is the inverse of the
connect_loci
> method. I'll go check out what you did.
That's pretty much what I tried to do. I just stared at connect_loci
for a long while and then tried to reverse all of the changes it made.
> Can we put a blank database container in one of the main
> containers/directories?
>
> $LOCIHOME/back/private/container/
>
> Blank containers are wrappers with an XML description (like all
loci),
> right?
Right--I think this shouldn't be a big problem. I need to start
thinking more about how to create permanent storage of xml to it can
reopened.
> As for keeping 'permanent' loci 'out of the way', How about having a
'hide
> locus' option that makes a locus invisible although not deleted?
This is a neat idea, but might be hard to keep track of, both
programmatically and the user. I know that if my icons could be made
invisible I would forget about half of them and end up with all kinds
of "invisible" junk that is just taking up space. But maybe that's
just me...
> What may be confusing, and I'm not sure how much I wrote about this
to you,
> is
> that the front-end(s) and the middleware will communicate by sending
XML tags
> back and forth. And the tags are commands. Here's an example:
>
> gi requests selection of
locus
> middle approves
I remember something about this from before, but I'm not positive that
I completely get it. Which events on a workspace will generate this
kind of xml dialog?
Everything? (ie. selects, moves, etc...) It seems to me that
things like this would be better left to the front end and just leave
the middle to deal more with issues that involve more "permanent"
changes (like connections). I am just worried that a lot of talking
between front and middle might slow things down, but then again, what
do I know about speed issues?
Also, I wonder why we need this kind of dialog--why can't we just
talk back and forth in python? It seems like even with a web
interface, you'll have to have some kind of language generating the
tags and recieving the responses, and why not make that python?
> allows us to do that. Heck, we can even 'play back' the entire work
session,
> with the workspace reenacting for the user what was done. Cooooool.
The idea is *really* cool, but I just worry about the implementation
time for an xml communciation pathway like this. Wouldn't this be a
lot of work?
> Gary and I developed this approach together. If you have more
questions,
> perhaps Gary can join in on the conversion ;-)
It seems like with all of the separation between middleware and
frontendware beginning to become clearer in my mind it might make
sense for me to focus more on middleware work (which needs *a lot* of
work), especially since your ToDo stuff is focused on frontend stuff.
This is a fine arrangement for me--who needs to look at pretty
pictures while they're programming? Certainly not me :-)
Brad
From chapmanb at arches.uga.edu Mon Feb 21 21:06:59 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] G Van Domselaar TODO 20000218
Message-ID: <200002220210.VAA78366@archa10.cc.uga.edu>
Gary wrote:
>> Is there a book on GNOME & CORBA now? Or are you referring to
online docs?
>
> Yeah, the online docs are worth reading a couple of times. If anyone
> can recommend a good book on CORBA for me, I'd appreciate that as
well.
> Brad? You seem to be doing pretty well; I see your posts all over
> biopython ;-)
Hmmm! I think you are definately overestimating my corba skills...
Everything that I've looked at has pretty much been stuff from the
list. Basically, I read through some really basic Corba stuff (on the
omg page and elsewhere) about 100 million times until I could finally
manage to grasp the general concept of what was going on. Then I
started into reading the Fnorb docs (which I think are a pretty good
intro to things, especially for python) and then headed on into the
Bonobo docs (very enlightening for me after the 13th or 14th time
through :).
From there, I've been looking at as much code as I can get my
hands on, and also am using a C++/Corba book for other references
(Vogel et al. C++ Programming with Corba). The python mapping spec was
just recently approved, so that is also useful. Of course, I feel like
I've doubled my knowledge in a short time by actually coding in it,
and spending tons of time staring at inscrutible CORBA generated
errors (it's amazing how you can get multiple pages of stack trace and
still not have any idea what is going on with the error :).
I'd really like to see Loci move into more corba stuff.
Personally, I'd like to use corba and Loci to talk with the fast Sun
in my lab and get it to do my EST clustering for me. I'll write more
about CORBA in a second, though...
>OpenDX also uses this approach. Actually, Brad, did you ever receive
>those rough Loci architecture drafts that Jeff and I hacked together?
I
>wouldn't mind making a wp doc from those and posting it to the group,
>once it gets the stamp of approval. Maybe I should add _that_ to _my_
>TODO list.
No, I haven't had the pleasure to scope these out yet. I'd be very
interested to see them, whenever they come together.
Brad
From chapmanb at arches.uga.edu Mon Feb 21 21:24:29 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] more on Eazel
Message-ID: <200002220227.VAA171848@archa10.cc.uga.edu>
> "This summer, Eazel plans to begin offering a free user interface --
an
> icon-based software control system that can be downloaded from the
> Internet..."
>
> Should we (Loci) be concerned? It's based on Gnome too.
The article is kind of scary. This project is pretty hard
core--they've got lots of really good designers working on it, they
appear to be pretty buddy/buddy with the Gnome people, and they have a
whole room full of cubicles set up for it (oh no!).
I don't think Loci has much to worry about from the
bioinformatics standpoint, but it is really worrysome if we would want
to imagine Loci as an "alternative" Gnome desktop. I don't think a few
part time coders have much chance of competing with a powerful thing
like this Eazel project, at least not if we are gunning for the same
goals.
Personally, I'd like to see Loci drop back off trying to be an all
purpose desktop and focus more on bioinformatics specific stuff. It is
just awfully intimidating for me to think about all of the code that
will have to be churned out before Loci could be workable as a
general workspace. Just focusing on bioinformatics stuff seems as
least a little more imaginable.
My vote (if we are voting :-) would be to have Loci be a corbafied
GUI for lots of bioinformatics programs. I think if we focus on this
we could get a lot of functionality quickly by interfacing with
Bioperl/python/java through their new idl, could use the Sever half of
AppLab for wrapping programs (for now) and could also look at the
millions of corba interfaces being developed at EBI. This would give
us something useful quicker, and then we could step back to look at
other goals. Just my two cents on this...
Brad
From bizzaro at geoserve.net Tue Feb 22 07:31:55 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
References: <200002220200.VAA106850@archa10.cc.uga.edu>
Message-ID: <38B281BB.2483BAB4@geoserve.net>
Brad Chapman wrote:
>
> Right--I think this shouldn't be a big problem. I need to start
> thinking more about how to create permanent storage of xml to it can
> reopened.
I'm leaning toward using the container directories to hold
(1) The actual programs, files, etc. (often symlinks)
(2) Loci wrappers
(3) And XML descriptions
As opposed to the directory structure we have now that separates wrappers and
containers.
Brad, this is part of the reason I want to see Loci restricted from accessing
anything in the filesystem.
As an example, 'ls' would have the following files in the container directory:
$LOCIHOME/back/private/container/
ls@ (symlink)
ls.wrap (wrapper)
ls.xml (xml description)
And maybe also
ls.icon (icon for workspace)
But the workspace will only 'show' the processor 'ls' in the container. The
others are hidden.
> This is a neat idea, but might be hard to keep track of, both
> programmatically and the user. I know that if my icons could be made
> invisible I would forget about half of them and end up with all kinds
> of "invisible" junk that is just taking up space. But maybe that's
> just me...
Well, I was thinking that the popup menu would keep a list of invisible loci.
> > middle approves
>
> I remember something about this from before, but I'm not positive that
> I completely get it. Which events on a workspace will generate this
> kind of xml dialog?
> Everything? (ie. selects, moves, etc...)
No, not everything.
> It seems to me that
> things like this would be better left to the front end and just leave
> the middle to deal more with issues that involve more "permanent"
> changes (like connections).
That's exactly right.
Whenever something is 'done' by the front-end that needs to be communicated to
the middleware (e.g., connections made/broken), an XML tag is generated much
like the comments tags I just implemented.
Do you see how the comments are spit out by the workspace now?
The XML commands will appear in the same stream. It's very simple.
> I am just worried that a lot of talking
> between front and middle might slow things down, but then again, what
> do I know about speed issues?
I imagine the dialog would proceed at a human-readable pace for even the
busiest sessions.
> Also, I wonder why we need this kind of dialog--why can't we just
> talk back and forth in python? It seems like even with a web
> interface, you'll have to have some kind of language generating the
> tags and recieving the responses, and why not make that python?
Because...
(1) We want to allow front-ends to be made in languages other than Python.
(2) We want to be able to use standard IPC protocols like HTTP.
(3) We want a 'transcript' that can be read back by Loci and humans.
> The idea is *really* cool, but I just worry about the implementation
> time for an xml communciation pathway like this. Wouldn't this be a
> lot of work?
I don't think so. We'll need an input queue and maybe an output queue, but
otherwise we're dealing with print statements (or the equivalent).
> It seems like with all of the separation between middleware and
> frontendware beginning to become clearer in my mind it might make
> sense for me to focus more on middleware work (which needs *a lot* of
> work), especially since your ToDo stuff is focused on frontend stuff.
> This is a fine arrangement for me--who needs to look at pretty
> pictures while they're programming? Certainly not me :-)
I have much more fun (and that's what this is all about) with human interface
design than middleware design. And since we have 2 cooks and 2 pots, it's
probably best that we each choose our favorite to cook with.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Tue Feb 22 08:05:13 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] more on Eazel
References: <200002220227.VAA171848@archa10.cc.uga.edu>
Message-ID: <38B28988.5CA0725@geoserve.net>
Brad Chapman wrote:
>
> The article is kind of scary. This project is pretty hard
> core--they've got lots of really good designers working on it, they
> appear to be pretty buddy/buddy with the Gnome people, and they have a
> whole room full of cubicles set up for it (oh no!).
The article says Gnome and Eazel were at one time going to become a single
team, but they weren't agreeing on a number of issues. It says instead Gnome
will concentrate on the 'middleware', while Eazel concentrates on the GUI.
(HelixCode will work on the office suite.)
> I don't think Loci has much to worry about from the
> bioinformatics standpoint, but it is really worrysome if we would want
> to imagine Loci as an "alternative" Gnome desktop. I don't think a few
> part time coders have much chance of competing with a powerful thing
> like this Eazel project, at least not if we are gunning for the same
> goals.
I'm just wondering if they'll pick up on the 'connect-the-dots' paradigm. But
I read how Eazel wants to make Linux easier to use for the compu-phobic than
Windows and even the Mac. Do you think Loci will be simpler than the Mac? I
don't think so.
I believe there may be some connect-the-dots in Eazel, but not to the extent of
Loci. Loci will be more difficult because it will be very flexible and
powerful. But then again, flexibility and power can be layered.
> Personally, I'd like to see Loci drop back off trying to be an all
> purpose desktop and focus more on bioinformatics specific stuff. It is
> just awfully intimidating for me to think about all of the code that
> will have to be churned out before Loci could be workable as a
> general workspace. Just focusing on bioinformatics stuff seems as
> least a little more imaginable.
Well, I was thinking about Loci working as a desktop when I heard that Havoc
might use the Gnome canvas (what Loci's gi is based on) as the root window for
Gnome. It goes without saying the possibilities that would open for Loci.
But, as you say, we don't have the resources to compete with other desktop
projects, and we probably wouldn't even get the cooperation of the Gnome team.
> My vote (if we are voting :-) would be to have Loci be a corbafied
> GUI for lots of bioinformatics programs. I think if we focus on this
> we could get a lot of functionality quickly by interfacing with
> Bioperl/python/java through their new idl, could use the Sever half of
> AppLab for wrapping programs (for now) and could also look at the
> millions of corba interfaces being developed at EBI. This would give
> us something useful quicker, and then we could step back to look at
> other goals. Just my two cents on this...
Talks with Gary (for those who don't know, Gary and I met in person over a
week's time to hash out some design issues) led me to start calling Loci a
'connectivity broker'. This means that Loci will be agnostic to the
communications protocol used by the back-end program. CORBA, HTTP, COM, UNIX
pipes, XML_RPC, etc. can all be supported if the support is 'plugged in' to
Loci. Why?
BECAUSE MANY, MANY PROGRAMS HAVE THEIR COMMUNICATIONS
PROTOCOL BUILT-IN (e.g, Apache), AND FORCING THESE PROGRAMS
TO CHANGE PROTOCOLS WOULD BE A MESS AND JUST PLAIN WRONG(TM).
AND LOCI WOULD OTHERWISE BECOME LIMITED TO WORKING ONLY WITH
PROGRAMS THAT ARE COMPATIBLE WITH...CORBA, OR WHATEVER.
But, you're right that the first programs to make work under Loci should be
bioinformatics apps. We're bioinformaticists, right? However, I still want
non-bioinformaticists to see the capabilities here. Non-bioinformatics
programmers outnumber us, how many to one? 10, 100, 1000? If you get these
guys excited about Loci, it'll really take off!
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Wed Feb 23 01:55:22 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] G Van Domselaar TODO 20000218
References: <200002220210.VAA78366@archa10.cc.uga.edu>
Message-ID: <38B3845A.C91E37F8@redpoll.pharmacy.ualberta.ca>
Brad Chapman wrote:
>
> Hmmm! I think you are definately overestimating my corba skills...
> Everything that I've looked at has pretty much been stuff from the
> list. Basically, I read through some really basic Corba stuff (on the
> omg page and elsewhere) about 100 million times until I could finally
> manage to grasp the general concept of what was going on.
Then I'll do that too!
Then I
> started into reading the Fnorb docs (which I think are a pretty good
> intro to things, especially for python) and then headed on into the
> Bonobo docs (very enlightening for me after the 13th or 14th time
> through :).
Oh cripes, my reading list is piling up!
> From there, I've been looking at as much code as I can get my
> hands on, and also am using a C++/Corba book for other references
> (Vogel et al. C++ Programming with Corba).
Oh geez, I just gotta get that one too.
> I'd really like to see Loci move into more corba stuff.
> Personally, I'd like to use corba and Loci to talk with the fast Sun
> in my lab and get it to do my EST clustering for me. I'll write more
> about CORBA in a second, though...
Yeah that would be really sweet.
>
> >OpenDX also uses this approach. Actually, Brad, did you ever receive
> >those rough Loci architecture drafts that Jeff and I hacked together?
> I
> >wouldn't mind making a wp doc from those and posting it to the group,
> >once it gets the stamp of approval. Maybe I should add _that_ to _my_
> >TODO list.
>
> No, I haven't had the pleasure to scope these out yet. I'd be very
> interested to see them, whenever they come together.
Funny, I thought I cc'd them to you when Jeff and I were haggling over
some of the details, I'll see if i can find them and resend them to ya.
Regards,
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From gvd at redpoll.pharmacy.ualberta.ca Wed Feb 23 02:00:06 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] more on Eazel
References: <200002220227.VAA171848@archa10.cc.uga.edu> <38B28988.5CA0725@geoserve.net>
Message-ID: <38B38576.DEF2B300@redpoll.pharmacy.ualberta.ca>
"J.W. Bizzaro" wrote:
>
> Talks with Gary (for those who don't know, Gary and I met in person over a
> week's time to hash out some design issues) led me to start calling Loci a
> 'connectivity broker'. This means that Loci will be agnostic to the
> communications protocol used by the back-end program. CORBA, HTTP, COM, UNIX
> pipes, XML_RPC, etc. can all be supported if the support is 'plugged in' to
> Loci. Why?
>
> BECAUSE MANY, MANY PROGRAMS HAVE THEIR COMMUNICATIONS
> PROTOCOL BUILT-IN (e.g, Apache), AND FORCING THESE PROGRAMS
> TO CHANGE PROTOCOLS WOULD BE A MESS AND JUST PLAIN WRONG(TM).
> AND LOCI WOULD OTHERWISE BECOME LIMITED TO WORKING ONLY WITH
> PROGRAMS THAT ARE COMPATIBLE WITH...CORBA, OR WHATEVER.
Word.
>
> But, you're right that the first programs to make work under Loci should be
> bioinformatics apps.
And it would be nice if we could the the corba connectivity up and
running right away. There's a lot of excitement with bioperl,
biopython, ebi, etc etc on corba connectivity, so we could possibly
recruit some help from these groups to get it up and running.
Regards,
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From chapmanb at arches.uga.edu Wed Feb 23 08:49:17 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
Message-ID: <200002231352.IAA183650@archa10.cc.uga.edu>
> Whenever something is 'done' by the front-end that needs to be
communicated
> to
> the middleware (e.g., connections made/broken), an XML tag is
generated much
> like the comments tags I just implemented.
>
> Do you see how the comments are spit out by the
workspace
> now?
> The XML commands will appear in the same stream. It's very simple.
I just finished revamping the xml and starting to get the front and
middle apart, and I'm having a better feeling for your idea and I'm
going to start gunning for this communication method asap. I've got a
question about it, though (of course!):
How "dumb" is the front end? What things exactly should it be doing?
The sticking point that I'm having right now is trying to figure out
what the jobs of the front and the middle are in filling a container
with gui info.
It would make the most sense to me if the front end were able to parse
xml files (so it can build the gui representation of a container
itself--like it does right now). So, if I'm thinking of things right
we'd have the following dialog:
FE = front-end M = middle
FE: (Needs to get the info for a container on the workspace)
M: (Recieves request, then grabs everything in the container tags from
the xml file and sticks it into a new xml file)
Return the information (somehow--as DOM? as a link to an XML file? as
the XML itself?)
Or something like this... Am I on the right track here?
> (1) We want to allow front-ends to be made in languages other than
> Python.
> (2) We want to be able to use standard IPC protocols like HTTP.
> (3) We want a 'transcript' that can be read back by Loci and
humans.
I will admit that I don't know *anything* about how http works, or
even the first place to get started (maybe Gary can give me some
clues?) but for right now I'll have the communication go on via a
reciever and sender class on each side, and then I can start to
incoporate http later.
> I have much more fun (and that's what this is all about) with human
interface
> design than middleware design. And since we have 2 cooks and 2
pots, it's
> probably best that we each choose our favorite to cook with.
I'm working to make a clean split right now, and then I'll build
up the middleware so it can do a lot more than it currently does right
now. I actually managed to draw out a picture of Loci
intra/inter-communication on a piece of paper, so I think I have an
idea of what needs to happens and feel fairly focused right now. Of
course, things will probably get blurry for me really quick...
Anyways, my artistic skills are next to zero, so I should
definately be kept as far away from GUIs as possible.
BTW Jeff, I like the new container locus backrground!
Brad
From chapmanb at arches.uga.edu Wed Feb 23 09:04:58 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] more on Eazel
Message-ID: <200002231408.JAA89832@archa12.cc.uga.edu>
Jeff wrote:
> Talks with Gary (for those who don't know, Gary and I met in person
over a
> week's time to hash out some design issues) led me to start calling
Loci a
> 'connectivity broker'. This means that Loci will be agnostic to the
> communications protocol used by the back-end program. CORBA, HTTP,
COM, UNIX
> pipes, XML_RPC, etc. can all be supported if the support is 'plugged
in' to
> Loci.
This makes a lot of sense, and I don't want to make Loci
CORBA-specific. I just think it might be a good idea to start with
corba connections to the backend and then work from there to add
other protocols, etc. I think there are a couple of advantages to
using CORBA first:
1. There is already a nice iterface (in the idl) as a starting point
for the connection which will make things easier, I think, when we're
still feeling around in the dark trying to connect things to Loci.
2. Although any single corba connection to a program is more difficult
than a single unix pipe connection to a program, there is a lot more
power in a single program. For instance, connecting with
biopython/perl/java will give us lots of functions to play with,
instead of just one. Or think about OpenDX with the corba connections
Harry will be setting up :-)
3. There is a lot o' love for corba in bioinformatics, so likely we'll
be able to grab a lot of programs/databases with this approach.
Jeff wrote:
> But, you're right that the first programs to make work under Loci
should be
> bioinformatics apps. We're bioinformaticists, right? However, I
still want
> non-bioinformaticists to see the capabilities here.
Non-bioinformatics
> programmers outnumber us, how many to one? 10, 100, 1000? If you
get these
> guys excited about Loci, it'll really take off!
You're right, of course! I just think with just a few of us now, we
should gun for something "manageable" but leave things open enough to
add on later. Otherwise we're going to be swamped.
Gary wrote:
> And it would be nice if we could the the corba connectivity up and
> running right away. There's a lot of excitement with bioperl,
> biopython, ebi, etc etc on corba connectivity, so we could possibly
> recruit some help from these groups to get it up and running.
Well, I don't know about help (it seems like all of the projects are
pretty swamped with ideas but not enough people to help with them!),
but it would be really cool to get it working!
Brad
From bizzaro at geoserve.net Wed Feb 23 10:11:52 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
References: <200002231352.IAA183650@archa10.cc.uga.edu>
Message-ID: <38B3F8B8.13DD9F34@geoserve.net>
Brad Chapman wrote:
>
> I just finished revamping the xml and starting to get the front and
> middle apart, and I'm having a better feeling for your idea and I'm
> going to start gunning for this communication method asap. I've got a
> question about it, though (of course!):
Great. Fire away.
> How "dumb" is the front end? What things exactly should it be doing?
> The sticking point that I'm having right now is trying to figure out
> what the jobs of the front and the middle are in filling a container
> with gui info.
We'll have to come up with a complete 'vocabulary' for _any_ front-end and for
the middleware. We're defining a (rather odd) API here.
> It would make the most sense to me if the front end were able to parse
> xml files (so it can build the gui representation of a container
> itself--like it does right now).
Right, the middleware gives the front-end ONLY WHAT IT NEEDS TO KNOW. When a
windowlet is opened in the gi workspace, it needs to know what widgets go in
there. But remember our earlier conversations about this: The middleware
provides high-level XML descriptions of the interface; each front-end
interprets it differently.
> So, if I'm thinking of things right
> we'd have the following dialog:
>
> FE = front-end M = middle
>
> FE: (Needs to get the info for a container on the workspace)
>
Right. When the gi windowlet is created, the FE will need to know what goes in
it.
> M: (Recieves request, then grabs everything in the container tags from
> the xml file and sticks it into a new xml file)
> Return the information (somehow--as DOM? as a link to an XML file? as
> the XML itself?)
As XML in the same pipeline as the request.
> Or something like this... Am I on the right track here?
I think so. Here's how I'd put it:
There is an XML description of locus X in a container.
The user uses gi to DnD locus X out of the container and onto the workspace.
(I think the FE's knowledge of the location may be more limited.)
The middleware checks the directory for locus X of id 'blabla1', XML and
wrapper.
The middleware find locus X XML and wrapper, and puts the XML in the database.
Being in the database, locus X is now considered 'on the workspace'.
Since this operation was successful, the middleware returns
And since the gi got confirmation, it proceeds to create locus X on the
workspace. This involves, of course, putting the icon, symbol and windowlet on
the workspace. So, perhaps the middleware needs to continue with providing
this information. It returns:
(symbol comes from knowing the locus type)
(now the middleware gives the interface description)
(Don't take my XML style as law here.)
The interface description is rather vague, but this can be interpreted
differently by different front-ends. The gi front-end may make a windowlet
like so (using pygtk or libglade):
+-------------------+
| |
| This is a locus |
| |
| +----------+ |
| | Okay | |
| +----------+ |
| |
+-------------------+
The natural language interface may come up with something like this:
This is a locus
Okay? > _
> > (1) We want to allow front-ends to be made in languages other than
> > Python.
> > (2) We want to be able to use standard IPC protocols like HTTP.
> > (3) We want a 'transcript' that can be read back by Loci and
> humans.
>
> I will admit that I don't know *anything* about how http works, or
> even the first place to get started (maybe Gary can give me some
> clues?) but for right now I'll have the communication go on via a
> reciever and sender class on each side, and then I can start to
> incoporate http later.
The HTTP interface will be a bit of a challenge to make, since it doesn't work
well with the streaming dialog model we're using: Web pages are static. But I
imagine there will be a common Web page called the 'workspace', just as with
the other front-ends, and subsequent Web pages will be generated according to
actions taken by the user. Much of the continuous dialog will have to go on in
the background unbeknownst to the Web user.
> I'm working to make a clean split right now, and then I'll build
> up the middleware so it can do a lot more than it currently does right
> now. I actually managed to draw out a picture of Loci
> intra/inter-communication on a piece of paper, so I think I have an
> idea of what needs to happens and feel fairly focused right now. Of
> course, things will probably get blurry for me really quick...
I was planning on getting gi to puke out some XML tags as things are done by
the user. I think this will help you see what the middleware has to respond
to. Let's work at developing the vocabulary piecemeal rather than all-at-once.
> Anyways, my artistic skills are next to zero, so I should
> definately be kept as far away from GUIs as possible.
> BTW Jeff, I like the new container locus backrground!
Thanks. I thought the folder icon would make us think 'Mac' more than the
cylinder would :-)
I'd like to work on making groovy icons and themes, but it would take too much
time away from programming (not that I'm hacking all that much right now). I
know a couple artists who could help in this area. Gary's pretty handy with
The GIMP, but his time working on the new server is too valuable. My brother
is good too, but I have a hard time getting him interested in my projects.
Anyway, it's something that will come with time. Hey, if Loci takes off, we
may get a loci.themes.org page :-)
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From chapmanb at arches.uga.edu Thu Feb 24 09:20:45 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
Message-ID: <200002241423.JAA70558@archa10.cc.uga.edu>
> We'll have to come up with a complete 'vocabulary' for _any_
front-end and
> for
> the middleware. We're defining a (rather odd) API here.
Agreed!
> I was planning on getting gi to puke out some XML tags as things are
done by
> the user. I think this will help you see what the middleware has to
respond
> to. Let's work at developing the vocabulary piecemeal rather than
> all-at-once.
This makes sense, and is the approach I've been using with the other
xml so far. I started trying to have a DTD, but I change things so
much right now as I'm learning, that it doesn't make sense to do this.
As things become clearer this would be something to do.
I started making the front talk to the middle via xml in the changes I
just committed. I've started with connections, and I made the front
send the middle the following XML:
This is just a semi-modification on what you were talking about before
(to make it valid XML so I can use DOM to work with it). I figured
that other actions can be a modification of this.
Right now I'm just passing the info as a big string o' XML and
parsing it from this. I took a little look at the httplib library in
the python distribution, and it seems like it might be useful (at
least, there are send and reply functions to call). Maybe I'll try
playing with this, but as you said, I'm not positive how to do it
with "streaming" data. We'll see, I guess...
> icon="back/private/container/locusx.icon">
> (symbol comes from knowing the locus type)
>
>
> (now the middleware gives the interface description)
>
>
>
What kind of information do you want the middle to give to the front?
Would something like:
Error: Loci cannot be connected
be sufficient. I think we should keep the chatting to a minimum since
we have
to deal with everything we pass. So, if you send the middle a request
to connect it either does it and returns "Success: Loci connected" or
send an "Error" if it cannot. Then the front can decide what it wants
to do. How does this sound?
Even though it is a mess to untangle them, it will be pretty cool
to have the middle and front finally free!
Brad
From chapmanb at arches.uga.edu Thu Feb 24 10:27:23 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] Example Client/Server http streaming
Message-ID: <200002241530.KAA147122@archa10.cc.uga.edu>
Hello all!
I was searching around for some example code to build a simple
http server and client so that we could try to pass info between the
front and middle, and found an excellent example:
http://www.mems-exchange.org/exchange/software/microscope/.
It's a remotely controlled mircoscope with a streaming dialog
exchange (check out the network protocol link). Neat, I think I'm
going to mine it as a model for our dialog.
Brad
From bizzaro at geoserve.net Thu Feb 24 10:46:02 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] J.W. Bizzaro; TODO 20000218
References: <200002241423.JAA70558@archa10.cc.uga.edu>
Message-ID: <38B5523A.9B82028E@geoserve.net>
Brad Chapman wrote:
>
> I started making the front talk to the middle via xml in the changes I
> just committed. I've started with connections, and I made the front
> send the middle the following XML:
>
>
>
>
>
>
>
>
> This is just a semi-modification on what you were talking about before
> (to make it valid XML so I can use DOM to work with it). I figured
> that other actions can be a modification of this.
That looks very nice, much better than my illegal XML hack.
> Right now I'm just passing the info as a big string o' XML and
> parsing it from this.
That's pretty much what I had in mind.
> I took a little look at the httplib library in
> the python distribution, and it seems like it might be useful (at
> least, there are send and reply functions to call). Maybe I'll try
> playing with this, but as you said, I'm not positive how to do it
> with "streaming" data. We'll see, I guess...
I have attached exploop.py (an Expect for Python) and eventloop.py (needed by
exploop.py). Perhaps these will be of some help in learning how to make a
streaming dialog.
> What kind of information do you want the middle to give to the front?
> Would something like:
>
>
> Error: Loci cannot be connected
>
>
> be sufficient.
Could we use a tag to identify the error, instead of a string?
Loci cannot be connected.
> I think we should keep the chatting to a minimum since
> we have
> to deal with everything we pass. So, if you send the middle a request
> to connect it either does it and returns "Success: Loci connected" or
> send an "Error" if it cannot. Then the front can decide what it wants
> to do. How does this sound?
Yeah, that sounds good.
> Even though it is a mess to untangle them, it will be pretty cool
> to have the middle and front finally free!
Yes.
You the man!
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
-------------- next part --------------
#! /usr/bin/env python
#
######
# $Id: exploop.py,v 1.5 1997/01/27 19:11:59 timo Exp $
#
# Depends on eventloop.py(c), which may be found at
# ftp://ftp.bbn.com/pub/timo/python/eventloop.py
#
######
# Inspired by pyexpect, "A Poor Man's Expect", from Mitch Chapman
#
######
"""
Need to document the Expect interface here.
"""
import eventloop
import regex
import fcntl, FCNTL
def _defaultCB(P,E):
return "break"
# end _defaultCB
class Pattern:
"""
Need to document the Pattern object's public interface.
I expect (no pun intended) that Pattern will often be subclassed
so that additional information can be stored with each
pattern.
"""
def __init__(self, regexp="", command=_defaultCB):
"""__init__(self, regexp="", command=<_defaultCB>)
The paramenter 'regexp' is a *compiled* regular expression.
The function 'command' will be called when a match is found.
The default command simply returns 'break'.
"""
self.pattern = regexp
self.command = command
# end __init__
# end class Pattern
ExpectError = "ExpectError"
ExpectTimeout = "ExpectTimeout"
ExpectEOF = "ExpectEOF"
class Expect(eventloop.EventLoop):
"""
Need to add documentation for the Expect class.
In particular, describe the public interface.
"""
def __init__(self, inf, outf):
"""__init__(self, infile, outfile)
Constructor for an Expect instance. This routine automatically
sets the input file for non-blocking.
"""
eventloop.EventLoop.__init__(self)
# Set up for non-blocking I/O, as otherwise handleInput
# will block until it has read a whole boatload of characters.
fcntl.fcntl(inf.fileno(), FCNTL.O_NDELAY, 1)
fcntl.fcntl(inf.fileno(), FCNTL.F_SETFL, FCNTL.O_NONBLOCK)
self.__inf = inf
self.__outf = outf
self.AddFile(inf, self.handleInput, inf, None)
# end of __init__
def send(self, str):
"""send(self, string)
Send characters from string out file.
"""
self.__outf.write(str)
self.__outf.flush()
# end of send
def expect(self, patterns=[], timeout=None):
"""expect(self, patterns=[], timeout=None)
The expect method is modeled after the select call. The
parameter 'patterns' is a list of Pattern instances. If a
'timeout' is specified, then expect() will wait at most
'timeout' seconds before returning, with a 'None' value.
If a pattern is matched, then its command is called. If that
command returns a true value, then expect() will return the
matching Pattern.
"""
if hasattr(self, "pats"):
raise ExpectError, "You're already expecting something."
self.pats = patterns
# Clear the rcvd buffer and set our default result.
self.__rcvd = ""
# Set a timer if given. Call Mainloop
self.__timerID = None
if timeout:
self.__timerID = self.AddTimer(timeout, self.doTimeout)
result = self.MainLoop()
if timeout:
self.DeleteTimer(self.__timerID)
del self.pats, self.__timerID
return result
# end expect()
def doTimeout(self, event=None):
"""doTimeout(self, event=None)
Timeout has expired for current expect() call.
"""
del self.pats, self.__timerID
raise ExpectTimeout
# end doTimeout
def handleInput(self, file, option):
"""handleInput(self, file, option)
Read all available characters on input file 'file' and
sequentially compare them to the current patterns. Once a
match is found, handleInput removes all text from the
beginning of the input string until the end of the match.
Matches are checked sequentially. If a pattern matches,
then we remove the appropriate text *BEFORE* checking
the next pattern.
Parameter 'option' is unused for now.
"""
str = file.read()
if not str:
raise ExpectEOF
self.__rcvd = self.__rcvd + str
# Ok, let's look for a match
for i in self.pats:
while 1:
result = i.pattern.search(self.__rcvd)
if result < 0: # no match found
break
matchlen = result + len(i.pattern.group(0)) + 1
result = apply(i.command, (i, self))
self.__rcvd = self.__rcvd[matchlen:]
if result:
self.Cancel(i)
# end of while loop
# end of for loop...
# end handleInput()
# end class Expect
######################################################################
##
# Example code
##
def _testCB(pat, exp):
reg = pat.pattern
exp.send("\nMatch Found: " + `reg.group(0)` + "\n")
# end testCB
if __name__ == "__main__":
import sys, os
# Get current terminal settings
p = os.popen("stty -g")
savedterm = p.read()
p.close()
del p
# Set terminal to (near) raw mode
# It allows the terminal to handle RETURNs appropriately
## this works on my Solaris machine. YMMV
os.system("stty cs8 -icanon min 1 time 0 -isig -xcase -inpck")
exp = Expect(sys.stdin, sys.stdout)
# Create our Patterns
pats = []
pats.append( Pattern(regex.compile("[Pp]ython"), _testCB) )
pats.append( Pattern(regex.compile("s+tar"), _testCB) )
# This pattern uses the default Pattern callback
pats.append( Pattern(regex.compile("[Bb]ye")))
# Output a prompt of sorts
exp.send("\nYou have 20 seconds. Type 'Bye' or 'bye' to exit sooner.\n")
# Call expect()...
try:
matcher = exp.expect(pats, 20)
print "\nGood Bye"
except ExpectTimeout:
print "\nTime has expired"
except ExpectEOF:
print "\nInput closed"
os.system("stty "+ savedterm)
-------------- next part --------------
#!/usr/bin/env python
#
#####
# $Id: eventloop.py,v 1.4 1997/08/01 20:33:12 timo Exp $
#
#####
import select, time
class Event:
"""Event class
A base class for different Event types."""
def __init__(self, func=None, arg=None):
self.func = func
self.arg = arg
def __call__(self):
apply(self.func, self.arg)
# end class Event
class FileEvent(Event):
"""A File Event
We keep a reference to the file object. File objects have a tendency
to close when deleted, so this reference prevents the user from
accidentally closing the file without telling the EventLoop.
"""
def __init__(self, file, func, arg):
Event.__init__(self, func, arg)
self.file = file
self.fileno = file.fileno
return
# end __init__
# end class FileEvent
class TimerEvent(Event):
"""A Timer Event
The only interesting thing here is the need to generate a unique-id
for each timer.
"""
next_id = 1
last_id = 65535
in_use = []
def __init__(self, expire, func, arg):
Event.__init__(self, func, arg)
self.expire = expire
self.id = N = TimerEvent.next_id
# Update in_use array
TimerEvent.in_use.append(N)
# Make sure the next_id is unique
if N == TimerEvent.last_id:
N = 1
else:
N = N + 1
while N in TimerEvent.in_use:
N = N + 1
TimerEvent.next_id = N + 1
return
# end __init__
def __del__(self):
TimerEvent.in_use.remove(self.id)
# end __del__
# end class TimerEvent
LoopExit = "LoopExit"
class EventLoop:
"""EventLoop creates a select-based mainloop. Events may be
added as either timers, which 'fire' after a specified period,
or as fileobjects, which "trigger" when available for reading.
Once a timer fires, it is removed from the Eventloop. If you
want your timer to fire every N seconds, then you must call
AddTimer from your callback. (See example below.)
A fileobject can be any object with a 'fileno' method. A
file event must be explicitly removed via DeleteFile. In this
respect, FileEvents differ from TimerEvents.
"""
###
### Internally:
###
### We have one structure to keep file objects:
### __filelist == { fileno : file_object }
###
### We have one structure to keep timers:
### __timerlist == { expiretime : [timer ...] }
###
def __init__(self):
self.__filelist = {}
self.__timerlist = {}
return
# end __init__
def Cancel(self, val=None):
raise LoopExit, val
def MainLoop(self):
sf = self.__filelist
st = self.__timerlist
try:
# while-loop implements the mainloop
while 1:
delay = None # Indicates no timers
if st:
when = min( st.keys() ) # Next timer
now = time.time() # Current time
if now >= when:
self.FireTimers(when) # Fire any expired timers
continue
# else
delay = when - now # Delay until next timer
# Although undocumented,
# delay==None results in a blocking select() call.
r,w,e = select.select( sf.values(), [], [], delay)
# For-Loop handles any file activity
for File in r:
File()
# end while loop
except LoopExit, val:
return val
# should never reach here
return
# end MainLoop
def AddFile(self, obj, callback, *arg):
sf = self.__filelist
f_no = obj.fileno()
# if sf.has_key(f_no):
# raise ValueError, "FileNo already used!"
sf[f_no] = FileEvent(obj, callback, arg)
return
# end AddFile
def DeleteFile(self, obj):
sf = self.__filelist
f_no = obj.fileno()
del sf[f_no]
return
# end DeleteFile
def AddTimer(self, seconds, callback, *arg):
st = self.__timerlist
when = time.time() + seconds
tobj = TimerEvent(when, callback, arg)
if st.has_key(when):
st[when].append(tobj)
else:
st[when] = [tobj]
return tobj.id
# end AddTimer
def DeleteTimer(self, identifier):
st = self.__timerlist
for T in st.values():
for Timer in T:
if Timer.id == identifier:
when = Timer.expire
T.remove(Timer)
if st[when] == []: del st[when]
return
# We didn't find it
raise ValueError, "No timer with identifier" + `identifier`
# end DeleteTimer
def FireTimers(self, which):
st = self.__timerlist
TL = st[which]
del st[which]
for Timer in TL:
Timer()
return
# end FireTimer
# end class EventLoop
def _timertest(endtime):
global Ev
t_minus = endtime - time.time()
if t_minus <= 0:
print "Boom!!!"
Ev.Cancel()
print
print "You have", `int(t_minus) +1`, "seconds to comply."
print
Ev.AddTimer(10, _timertest, end)
# end _timertest
def _filetest(str, endtime):
global Ev
ans = sys.stdin.readline()
if ans[:-1] == str:
print "Hooray!"
Ev.Cancel()
print "Wrong! Try again."
# end _filetest
if __name__ == "__main__":
import sys
global Ev
phrase = "Python is my favorite language"
Ev = EventLoop()
print "Please type:"
print " ", phrase
end = time.time() + 30
Ev.AddFile(sys.stdin, _filetest, phrase, end )
Ev.AddTimer(0, _timertest, end)
Ev.MainLoop()
From bizzaro at geoserve.net Thu Feb 24 10:54:24 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] Example Client/Server http streaming
References: <200002241530.KAA147122@archa10.cc.uga.edu>
Message-ID: <38B55430.A74F9206@geoserve.net>
Brad Chapman wrote:
>
> I was searching around for some example code to build a simple
> http server and client so that we could try to pass info between the
> front and middle, and found an excellent example:
> http://www.mems-exchange.org/exchange/software/microscope/.
> It's a remotely controlled mircoscope with a streaming dialog
> exchange (check out the network protocol link). Neat, I think I'm
> going to mine it as a model for our dialog.
Interesting. It runs Python on the server end but Java on the client end.
Isn't CNRI where the Grail browser was made, and where Guido works?
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 24 12:30:34 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] filesystem container as composite widget
Message-ID: <38B56ABA.C3A98DB7@geoserve.net>
Locians,
Recall the composite locus that Brad made for the 'ls' program.
Now replace the text widget that printed out the directory listing with a list
widget (ordinary, column, tree, icon).
Now, isn't this the same as a filesystem container?
Perhaps we could add loci to the composite for...changing, making and removing
directories?
Hmmmm. An interesting thought.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 24 13:06:37 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:15 2006
Subject: [Pipet Devel] tapping the dialog stream
Message-ID: <38B5732D.88F3B2DA@geoserve.net>
Brad,
I'd like us to keep in mind, while the dialog system is being developed, that
we want to allow the dialog to be 'tapped' by another front-end.
All fronts will operate only by the permission of the middle. Therefore,
multiple fronts listening to the middle will operate _simultaneously_.
What's the advantage of this? Imagine being able to control the gi workspace
from the nli, or web, or any other front-end. And when we get the nli working
with speech recognition, imagine being able to control the gi by voice!
This is also important for 'recording' the dialog or producing a transcript.
As mentioned before, this transcript can act as an electronic notebook and be
'played back' like a tape recording.
It would even be helpful for development if we can tap into the dialog and spit
the XML out onto the screen.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 24 18:12:12 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] [Fwd: EFS and gnome/kde]
Message-ID: <38B5BACC.551B0096@geoserve.net>
EFS is an 'embedded file system', basically a file that acts like a filesystem,
with its very own directories and files.
I curious if this may be of some use to us.
Jeff
-------------- next part --------------
An embedded message was scrubbed...
From: bob@thestuff.net
Subject: EFS and gnome/kde (was Re: Request: Test suite for EFS.)
Date: Thu, 24 Feb 2000 03:24:43 -0600 (CST)
Size: 3488
Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000224/21caab37/attachment.mht
From gvd at redpoll.pharmacy.ualberta.ca Thu Feb 24 20:48:05 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol, was: J.W. Bizzaro; TODO 20000218
References: <200002231352.IAA183650@archa10.cc.uga.edu>
Message-ID: <38B5DF55.2EC74B7D@redpoll.pharmacy.ualberta.ca>
Brad Chapman wrote:
> I will admit that I don't know *anything* about how http works, or
> even the first place to get started (maybe Gary can give me some
> clues?) but for right now I'll have the communication go on via a
> reciever and sender class on each side, and then I can start to
> incoporate http later.
I'm not an http expert either; I merely proposed it because it is the
default communication protocol for XML transfer, and web-browsers use
it. When we get XML compliant web browsers, then we can connect
browsers to a loci engine. The crappy part about this is that, in order
to manipulate the DOM, we're stuck with java/javascript. I dont know of
any other way to do client-side processing through a browser, if there
is I would love to hear about it. Honestly, the whole web-interface
idea may be too much for us right now, although I know Dr. Lapointe is
interested, as is my roommate (who would like to participate in this
aspect of Loci's interface).
Newayz, here is the url to look at for the http rfc:
http://www.w3.org/Protocols/
Here's a little snippet from the latest rfc2126 (http/1.1):
______Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers [47]. A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
...
1.4 Overall Operation
The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI, and
protocol version, followed by a MIME-like message containing request
modifiers, client information, and possible body content over a
connection with a server. The server responds with a status line,
including the message's protocol version and a success or error code,
followed by a MIME-like message containing server information, entity
metainformation, and possible entity-body content.
Regards,
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From dlapointe at mediaone.net Thu Feb 24 21:40:34 2000
From: dlapointe at mediaone.net (David Lapointe)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol, was: J.W. Bizzaro; TODO 20000218
In-Reply-To: <38B5DF55.2EC74B7D@redpoll.pharmacy.ualberta.ca>
References: <200002231352.IAA183650@archa10.cc.uga.edu> <38B5DF55.2EC74B7D@redpoll.pharmacy.ualberta.ca>
Message-ID: <00022421595200.01417@gnomen>
On Thu, 24 Feb 2000, Gary Van Domselaar wrote:
> Brad Chapman wrote:
>
> > I will admit that I don't know *anything* about how http works, or
> > even the first place to get started (maybe Gary can give me some
> > clues?) but for right now I'll have the communication go on via a
> > reciever and sender class on each side, and then I can start to
> > incoporate http later.
Python has some modules (URLLIB, HTTPLIB,FTPLIB) for dealing with these.
Otherwise it's the same for everything sockets. Open a socket on a port, write and read from the
socket ( just like a file ).
Try this. Use your favorite simple web site
%telnet webssite 80
(stuff comes back)
HEAD / HTTPD/1.0
or
GET / HTTPD/1.0
If you want to write to a CGI, it's just a little more difficult. Basically
collect all of the name=value pairs into a big string, calculate the length of the string, construct the headers, send it
and get ready for the result. For http make sure you have a blank line between the headers and the content.
There are several header lines depending what you are doing. See "WebMaster in a Nutshell".
print "Content-length: %d\n\n%s",length(stringnamevalues),stringnamevalues,
--
.david
David Lapointe
I can't understand why people are frightened by new ideas. I'm
frightened of old ones -- John Cage
From chapmanb at arches.uga.edu Thu Feb 24 22:03:14 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol
Message-ID: <200002250306.WAA40098@archa12.cc.uga.edu>
Gary wrote:
> I'm not an http expert either; I merely proposed it because it is the
> default communication protocol for XML transfer, and web-browsers use
> it. When we get XML compliant web browsers, then we can connect
> browsers to a loci engine. The crappy part about this is that, in
order
> to manipulate the DOM, we're stuck with java/javascript. I dont
know of
> any other way to do client-side processing through a browser, if
there
> is I would love to hear about it. Honestly, the whole web-interface
> idea may be too much for us right now, although I know Dr. Lapointe
is
> interested, as is my roommate (who would like to participate in this
> aspect of Loci's interface).
Good timing, since I'm just programming/thinking on this right this
second!
Right now I'm starting to implement and work through the
microscope server example that I mentioned in my e-mail earlier today.
This server does a lot of what Jeff mentioned he wanted, including
allowing multiple connections to a single server. The connections
are established through sockets (socket programming = scary!) and the
server handles processing requests, authorizing users, and
returning information. It works with a web interface by creating a
simple http server that spits out a basic page and a jar file with the
client.
So, anyways, looking at this and looking at basic info on http led
me to have the following thoughts:
1. I don't think http as a communication protocol will give us a
multi-client/one server setup like we would like without a huge pain.
>From looking at things, http seems set up for a simple request and
response dialog, and I'm not positive how to manipulate it to do what
we want without having a huge middleware server with a lot of "web
interface" specific code.
2. How about if instead of relying on the middleware server to spit
out XML that will eventually be good enough to travel directly into a
browser (whenever browsers become sufficiently XML aware enough), we
require the web front to process the XML that the middle returns, and
then serve up web pages based on this? From what little I know about
Zope, it seems like it would be ideally suited to this task since I
think it's meant for publishing "dynamic" web pages like we would need
for Loci. This way, the developer of the front end could choose use a
"real" http server (instead of us having to program an http server)
and could also use other web server tools like MySQL or whatever. This
seems like it would free up the people interested in developing the
web interface to be a lot more creative in generating the user
interface and also to use more standard web tools that we actually
have now.
3. If the above two points make sense, then we now have a little
more flexibility for communication methods between front ends and the
middle. In this case, I would like to propose using corba (instead of
the sockets used in the microscope server example that I'm looking at)
to communicate between the front and the middle. This will give us a
lot of freedom for creating a nice interface and will allow front ends
to be built in any language. Initially, we could have corba servers
publish there IORs somewhere on the bioinformatics.org server, and
then as we got more users, have a dedicated loci program that
manages/distributes these IORs.
I also think corba might be a little kinder to us then
sockets/http in terms of a learning curve.
Again, I think that once we have corba working, the middle could
be extended later to use other protocols (once xml and browsers start
to get along better). But this would give us a way to create the web
interface with tools we have now.
Does this sound like a plan? What do the web interface people
think of this type of arrangement? Does it make sense? (I'm not much
o' a web programmer myself). If you think it might be worth a try, I
can whip up an idl interface to start with and we can go from there...
Brad
From bizzaro at geoserve.net Thu Feb 24 22:37:11 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol, was: J.W. Bizzaro; TODO 20000218
References: <200002231352.IAA183650@archa10.cc.uga.edu> <38B5DF55.2EC74B7D@redpoll.pharmacy.ualberta.ca>
Message-ID: <38B5F8E7.C67554A7@geoserve.net>
Gary Van Domselaar wrote:
>
> When we get XML compliant web browsers, then we can connect
> browsers to a loci engine. The crappy part about this is that, in order
> to manipulate the DOM, we're stuck with java/javascript. I dont know of
> any other way to do client-side processing through a browser, if there
> is I would love to hear about it.
I wouldn't process the XML on the client side but on the server side.
Have the Web interface (on the server side) build a workspace 'behind the
scenes'. The interface will make an HTML file for each locus (ideally), and a
hyperlink will be made for each locus connection. The user will then 'surf'
the workspace. How does that sound?
> Honestly, the whole web-interface
> idea may be too much for us right now, although I know Dr. Lapointe is
> interested, as is my roommate (who would like to participate in this
> aspect of Loci's interface).
I look forward to seeing it coded. But whoever takes on the project must
adhere to the API and paradigm used in the other fronts, which of course isn't
even defined yet. This API may not be familiar to CGI programmers, but the WWW
paradigm (for once in my life) must not dictate the design of the whole
application.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 24 23:14:09 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol
References: <200002250306.WAA40098@archa12.cc.uga.edu>
Message-ID: <38B60191.132ACE96@geoserve.net>
Brad Chapman wrote:
>
> It works with a web interface by creating a
> simple http server that spits out a basic page and a jar file with the
> client.
What makes it an 'http' server is simply that fact that the formatting, etc.
adheres to the http 4.0 protocol. Otherwise, it's just communication through a
socket. For Loci, we can throw most of the http stuff away.
I know Gary was pushing to get this dialog to happen over http so that the
middle and fronts can be in 2 different places. We can make something using
Internet sockets, but I think going through a big ol' natsy Web server like
apache is 90% overkill. AND it does not give us a number of the things we
need, including multicasting and persistence.
I think our first priority is to get the dialog running locally. Next we can
look at getting 2 middles to talk to each other over the Internet. And last,
we can look at getting the fronts and the middle talking over the net. I'm not
saying to not do it. We just need to take it one step at a time.
> 1. I don't think http as a communication protocol will give us a
> multi-client/one server setup like we would like without a huge pain.
> >From looking at things, http seems set up for a simple request and
> response dialog, and I'm not positive how to manipulate it to do what
> we want without having a huge middleware server with a lot of "web
> interface" specific code.
Again, http is overkill. We need an LTP: Locus Transfer Protocol.
> 2. How about if instead of relying on the middleware server to spit
> out XML that will eventually be good enough to travel directly into a
> browser (whenever browsers become sufficiently XML aware enough),
As I wrote in my last message, I think the XML needs to be processed by the
Loci front and not by the Web browser.
> we require the web front to process the XML that the middle returns, and
> then serve up web pages based on this?
Zactly.
> From what little I know about
> Zope, it seems like it would be ideally suited to this task since I
> think it's meant for publishing "dynamic" web pages like we would need
> for Loci.
It may work, but are we going to make THAT monster a requirement?
Perhaps a little php will do the trick.
> 3. If the above two points make sense, then we now have a little
> more flexibility for communication methods between front ends and the
> middle. In this case, I would like to propose using corba (instead of
> the sockets used in the microscope server example that I'm looking at)
> to communicate between the front and the middle.
Boy, corba has to sneak in somewhere ;-)
Are you proposing to run a 'streaming dialog' through corba? I didn't think it
was used for such a thing.
> I also think corba might be a little kinder to us then
> sockets/http in terms of a learning curve.
As David mentioned, sockets are pretty straight forward. I think corba is an
order of magnitude more complex.
> Again, I think that once we have corba working, the middle could
> be extended later to use other protocols (once xml and browsers start
> to get along better). But this would give us a way to create the web
> interface with tools we have now.
Please, please, don't let http and the Web paradigm dictate how Loci will work,
Brad.
Loci can use corba and http, having the appropriate extensions for them. But
we have to keep Loci as a protocol-agnostic broker for communications.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 24 23:21:50 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol
References: <200002250306.WAA40098@archa12.cc.uga.edu> <38B60191.132ACE96@geoserve.net>
Message-ID: <38B6035E.9F91B696@geoserve.net>
"J.W. Bizzaro" wrote:
>
> We need an LTP: Locus Transfer Protocol.
Well, uh, since we have 2 Internet connections to consider (middle-to-middle
and front-to-middle), we probably need 2 protocols. I was planning on calling
the middle-to-middle protocol 'LTP'.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Thu Feb 24 23:24:28 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol
References: <200002250306.WAA40098@archa12.cc.uga.edu> <38B60191.132ACE96@geoserve.net>
Message-ID: <38B603FC.F084133F@geoserve.net>
"J.W. Bizzaro" wrote:
>
> I think our first priority is to get the dialog running locally.
Just get the connection to work locally for now (front and middle on same
computer) so that you don't have to worry about authentication, etc.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Fri Feb 25 00:59:44 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] client/server communication layer
Message-ID: <38B61A50.D8F32FDB@redpoll.pharmacy.ualberta.ca>
I'm not sure if I got this entire msg, but...
Brad Wrote
>
> 2. How about if instead of relying on the middleware server to spit
> out XML that will eventually be good enough to travel directly into a
> browser (whenever browsers become sufficiently XML aware enough), we
> require the web front to process the XML that the middle returns, and
> then serve up web pages based on this? From what little I know about
> Zope, it seems like it would be ideally suited to this task since I
> think it's meant for publishing "dynamic" web pages like we would need
> for Loci. This way, the developer of the front end could choose use a
> "real" http server (instead of us having to program an http server)
> and could also use other web server tools like MySQL or whatever. This
> seems like it would free up the people interested in developing the
> web interface to be a lot more creative in generating the user
> interface and also to use more standard web tools that we actually
> have now.
Well now this is an interesting concept. If I catch your drift, you are
proposing that we use a web server to process the xml, and then
dyanamically generate the web page and send that to the browser.
Considering my distate for the development tools available to access the
DOM from the web client, I could go for that. It does seem a _little_
odd that we use xml to communicate between the client (gtk, web
_server_, and nli) if we go by this method. So...
>
> 3. If the above two points make sense, then we now have a little
> more flexibility for communication methods between front ends and the
> middle. In this case, I would like to propose using corba (instead of
> the sockets used in the microscope server example that I'm looking at)
> to communicate between the front and the middle. This will give us a
> lot of freedom for creating a nice interface and will allow front ends
> to be built in any language. Initially, we could have corba servers
> publish there IORs somewhere on the bioinformatics.org server, and
> then as we got more users, have a dedicated loci program that
> manages/distributes these IORs.
> I also think corba might be a little kinder to us then
> sockets/http in terms of a learning curve.
>
> Again, I think that once we have corba working, the middle could
> be extended later to use other protocols (once xml and browsers start
> to get along better). But this would give us a way to create the web
> interface with tools we have now.
So do you then propose to pass xml through corba, or to just drop xml
for client/middleware communication? If we go corba, i really don't see
the point of using xml.
> Does this sound like a plan? What do the web interface people
> think of this type of arrangement? Does it make sense? (I'm not much
> o' a web programmer myself). If you think it might be worth a try, I
> can whip up an idl interface to start with and we can go from there...
Why not?
>
> Brad
_______________________________________________
pipet-devel maillist - pipet-devel@bioinformatics.org
http://bioinformatics.org/mailman/listinfo/pipet-devel
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From chapmanb at arches.uga.edu Fri Feb 25 08:53:16 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol
Message-ID: <200002251356.IAA32910@archa10.cc.uga.edu>
> What makes it an 'http' server is simply that fact that the
formatting, etc.
> adheres to the http 4.0 protocol. Otherwise, it's just communication
> through a socket.
Okay, this makes sense. Sorry I'm a little confused about the ol' http
stuff. You'll have to keep in mind that 6 months ago I didn't know
the difference between a web browser and a web server :-O
> I know Gary was pushing to get this dialog to happen over http so
that the
> middle and fronts can be in 2 different places. We can make
something using
> Internet sockets, but I think going through a big ol' natsy Web
server like
> apache is 90% overkill. AND it does not give us a number of the
things we
> need, including multicasting and persistence.
My idea was that the web front would take care of all of the
serving for web pages, and the middle would only supply this Loci
Transfer Protocol (ie. XML back and forth). I figure that whoever does
the web front can use whatever server/helper programs that they need,
and I was just throwing Apache/Zope out there as ideas, since Gary
expressed some concern about the feasibility of things. I think
getting a loci front going in a web browser will take a lot of
creativity, so any tools that can help shouldn't be a problem!
Besides, if you get to require "monster" Gnome and Gtk for the
front end you are designing, I think anyone working on the web front
end could also require Zope/Apache :)
But, as I said, I don't know anything about web design, so
whatever people want to use is fine with me!
> I think our first priority is to get the dialog running locally.
Next we can
> look at getting 2 middles to talk to each other over the Internet.
And last,
> we can look at getting the fronts and the middle talking over the
net. I'm
> not saying to not do it. We just need to take it one step at a time.
Right, baby steps all of the way. I just uploaded my first baby step
with sockets to get the front and middle talking on a single machine.
I wrote a barely functional middle "socket" server based heavily on
the design of the microscope server, and then redirected the
connection stuff so it goes through the socket. So now we actually
have clean language independent separation between one small part of
the front and middle (yay!).
Okay, right now I have the middle socket server and the main Loci
program start up via two different scripts (to make it easier for me
to test things) so to start Loci now you need to first run:
./startMiddle.py &
and then:
./loci &
If you try and start up loci without the middle running you'll get a
socket error.
So it looks like we'll start doing things with sockets and see
where it goes....
> Boy, corba has to sneak in somewhere ;-)
But of course!
> Are you proposing to run a 'streaming dialog' through corba? I
didn't think
> it was used for such a thing.
Sure, I think it could. You can run multithreaded servers, and _I
think_ it supports callback functions.
>> I also think corba might be a little kinder to us then
>> sockets/http in terms of a learning curve.
>
> As David mentioned, sockets are pretty straight forward. I think
corba is an
> order of magnitude more complex.
I think that initially sockets are simpler, but I think things
might get more difficult as we want to do more complicated things.
This is where I think corba might be more suitable.
But you are right, maybe we should start with sockets and then see
if problems/limitations develop. Then maybe I'll be able to make a
better case for
corba...
> Loci can use corba and http, having the appropriate extensions for
them. But
> we have to keep Loci as a protocol-agnostic broker for
communications.
This makes sense, but I only want to have to support one communication
protocol from the front to the middle for now. Otherwise stuff will
get waaay too complicated for my brain to handle.
Brad
From chapmanb at arches.uga.edu Fri Feb 25 09:02:27 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] client/server communication layer
Message-ID: <200002251405.JAA157910@archa11.cc.uga.edu>
Gary wrote:
> Well now this is an interesting concept. If I catch your drift, you
are
> proposing that we use a web server to process the xml, and then
> dyanamically generate the web page and send that to the browser.
> Considering my distate for the development tools available to access
the
> DOM from the web client, I could go for that. It does seem a
_little_
> odd that we use xml to communicate between the client (gtk, web
> _server_, and nli) if we go by this method. So...
Right, I think the front should just be a web server front that
communicates with the middle. I _think_ Jeff also agrees with this.
This way, you can use any language you want to talk with the middle
(by sockets or corba), get the xml from the middle, and do whatever
you want with it. Then you can use anything in the bag o' web master
tricks to serve up nifty web pages.
Gary wrote:
> So do you then propose to pass xml through corba, or to just drop xml
> for client/middleware communication? If we go corba, i really don't
see
> the point of using xml.
If we use corba, I was still thinking of using the same interface (ie.
send data, return data) and not a really complicated interface (ie. a
special interface for connecting loci, a special interface for adding
loci, etc...). Then we will still need to have some way to
communicate structured information back and forth, and I think xml is
good for this, since we can then use the tools built for xml, and not
have to define our own language and parsers (which is what they do in
the microscope example I keep talking about).
> Why not?
I don't really know enough about corba to argue convincingly for it
now, so I think Jeff is right, we should start with the simple, and
see what happens from there.
Brad
From bizzaro at geoserve.net Fri Feb 25 09:53:07 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] client/server communication layer
References: <38B61A50.D8F32FDB@redpoll.pharmacy.ualberta.ca>
Message-ID: <38B69753.A07E08B9@geoserve.net>
Gary Van Domselaar wrote:
>
> Well now this is an interesting concept. If I catch your drift, you are
> proposing that we use a web server to process the xml, and then
> dyanamically generate the web page and send that to the browser.
I believe Brad and I are thinking about the same thing here:
Loci Web front == Web server-side persistent CGI
It's a little confusing, because we're saying that Loci's front-end is a Web
back-end.
> Considering my distate for the development tools available to access the
> DOM from the web client, I could go for that. It does seem a _little_
> odd that we use xml to communicate between the client (gtk, web
> _server_, and nli) if we go by this method. So...
I most definitely would NOT pass Loci's XML to a Web browser.
> So do you then propose to pass xml through corba, or to just drop xml
> for client/middleware communication? If we go corba, i really don't see
> the point of using xml.
This is our old delema: We want to use modern tools like XML and CORBA, but
there is no _need_ to use XML if we're using CORBA.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 25 10:32:32 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol
References: <200002251356.IAA32910@archa10.cc.uga.edu>
Message-ID: <38B6A090.9BF31C1E@geoserve.net>
Brad Chapman wrote:
>
> > adheres to the http 4.0 protocol.
Err, sorry. I guess it's HTTP 1.0. HTML is 4.0.
> My idea was that the web front would take care of all of the
> serving for web pages, and the middle would only supply this Loci
> Transfer Protocol (ie. XML back and forth).
Xactamundo.
> I figure that whoever does
> the web front can use whatever server/helper programs that they need,
> and I was just throwing Apache/Zope out there as ideas, since Gary
> expressed some concern about the feasibility of things. I think
> getting a loci front going in a web browser will take a lot of
> creativity, so any tools that can help shouldn't be a problem!
Okay.
> Besides, if you get to require "monster" Gnome and Gtk for the
> front end you are designing, I think anyone working on the web front
> end could also require Zope/Apache :)
Touche ;-)
> But, as I said, I don't know anything about web design, so
> whatever people want to use is fine with me!
The Web front-end of Loci will require some creativity, but the developers
won't be suffering from a lack of tools. As you mentioned, there are many,
many tools out there for Web content generation. I think we can therefore
worry less about the needs of Loci's Web front-end and focus instead on being
innovative.
> Right, baby steps all of the way. I just uploaded my first baby step
> with sockets to get the front and middle talking on a single machine.
> I wrote a barely functional middle "socket" server based heavily on
> the design of the microscope server, and then redirected the
> connection stuff so it goes through the socket. So now we actually
> have clean language independent separation between one small part of
> the front and middle (yay!).
Yippie!
> Okay, right now I have the middle socket server and the main Loci
> program start up via two different scripts (to make it easier for me
> to test things) so to start Loci now you need to first run:
>
> ./startMiddle.py &
>
> and then:
>
> ./loci &
Well, you just hit on something I knew we would have to deal with. The script
'loci' in the root directory should be a command-line program that launches the
fronts and middle as separate processes. Right now, it has some Gnome stuff in
it, which it should NOT. This is a left-over from before our change in
directory structure.
Don't worry about making the 'loci' script work right, Brad. I want to add
that to my personal TODO.
> So it looks like we'll start doing things with sockets and see
> where it goes....
Good.
> I think that initially sockets are simpler, but I think things
> might get more difficult as we want to do more complicated things.
> This is where I think corba might be more suitable.
> But you are right, maybe we should start with sockets and then see
> if problems/limitations develop. Then maybe I'll be able to make a
> better case for corba...
If there is a glaring problem with using ordinary sockets, and CORBA can do
everything we want and better than sockets can, we'll use CORBA.
> > Loci can use corba and http, having the appropriate extensions for
> > them. But we have to keep Loci as a protocol-agnostic broker for
> > communications.
>
> This makes sense, but I only want to have to support one communication
> protocol from the front to the middle for now. Otherwise stuff will
> get waaay too complicated for my brain to handle.
I wouldn't characterize Loci's brokerage of different communications protocols
as being front-to-middle communication.
NOTE: THE MIDDLES BROKER COMMUNICATIONS BETWEEN BACK-ENDS! And there is NO
DIRECT COMMUNICATION BETWEEN FRONTS AND BACKS!
Front talks to middle
Middle talks to front
Middle talks to middle
Middle talks to back
Back talks to middle
>>Back talks to back<< (when connection has been brokered)
Here's a flowchart:
+-------+
| Front |
+-------+
| /|\
| |
SOCKET | | SOCKET
| |
\|/ |
+--------+
| Middle |/______________
+--------+\ |
/ \ |
SOCKET / \ SOCKET | SOCKET
/ \ |
+-----+/_/ \_\+-----+____|
| |\ /| |
| Back|_______________\|Back |_________\
| | ANY PROTOCOL /| | ETC. /
+-----+ +-----+
Can ya diggit? Yes I can!
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 25 10:58:55 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] modified flowchart and a plea
Message-ID: <38B6A6BF.9D57C726@geoserve.net>
Okay, this might be a little more accurate and informative:
+-------+
| Front |
+-------+
| /|\
| |
LOCAL | | LOCAL
| |
\|/ |
+--------+
| Middle |
+--------+
| /|\
| |
INTERNET | | INTERNET
| |
\|/ |
+--------+
| Middle |/______________
+--------+\ |
/ \ |
LOCAL / \ LOCAL | LOCAL
/ \ |
+-----+/_/ \_\+-----+____|
| |\ /| |
| Back|_______________\|Back |_________\
| | ANY PROTOCOL /| | ETC. /
+-----+ +-----+
Note that if the backs and fronts are on the same computer, the middle loops
back to itself via Internet connection.
The 'LOCAL' connection between Front and Middle is the streaming XML dialog
we've been talking about. It can be standard, _local_ IPC (inter-process
communication; my preference) or an Internet connection/RPC (remote procedure
call; Gary's preference).
The 'INTERNET' connection is something we haven't discussed at all. It
involves 2 middles talking to each other. Of course it can be via standard
Internet socket. Some may argue for CORBA...I wouldn't ;-)
There are also the 'LOCAL' connections between the middle and backs. I think
those should definitely be through ordinary, _local_ IPC. But the same
argument for having front-to-middle communication go through the Internet, can
be made for a middle-to-back connection.
Plea: Guys, for the sake of simplicity (and security!) can we just deal with
_one_ Internet connection (between middles)? At least until we've got this
stuff down to a science. What do you say?
Brad, the Python 'Expect' modules I sent you should be helpful for figuring out
local IPC.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 25 11:06:22 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] modified flowchart and a plea
References: <38B6A6BF.9D57C726@geoserve.net>
Message-ID: <38B6A87E.CF8DEBA@geoserve.net>
Also note that both 'LOCAL' and 'INTERNET' connections deal exclusively with
(or so _I_ want them to) XML.
> +-------+
> | Front |
> +-------+
> | /|\
> | |
> LOCAL | | LOCAL
> | |
> \|/ |
> +--------+
> | Middle |
> +--------+
> | /|\
> | |
> INTERNET | | INTERNET
> | |
> \|/ |
> +--------+
> | Middle |/______________
> +--------+\ |
> / \ |
> LOCAL / \ LOCAL | LOCAL
> / \ |
> +-----+/_/ \_\+-----+____|
> | |\ /| |
> | Back|_______________\|Back |_________\
> | | ANY PROTOCOL /| | ETC. /
> +-----+ +-----+
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 25 12:00:37 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] more fun with flowcharts
Message-ID: <38B6B535.E23F3E32@geoserve.net>
Okay, one more try. Back-ends (hosted applications) are on 2 different
computers:
+-------+
| Front |
+-------+
| /|\
| |
LOCAL | | LOCAL
| |
\|/ |
+--------+/_________________
| Middle |\ |
+--------+ |
| |
| | INTERNET
INTERNET | |
| |
\|/ |
+--------+ +--------+ LOCAL
| Middle | | Middle |/_____________
+--------+ +--------+\ |
/ |
LOCAL / |
/ |
+-----+/_/ +-----+___|
| |\ | |
| Back|____________________________________\|Back |
| | ANY PROTOCOL /| |
+-----+ +-----+
Backs appearing on the same computer as the front does, or other backs do, will
always mean the middle loops back to itself. So,
makes the middle call itself through an Internet socket. And,
does too. But,
tells the back to pipe its data to another back.
In any case, the local computer's URI should be kept as metadata so that the
data knows how to get back home.
Here is the same flowchart showing 2-way communcation at all points:
+-------+
| Front |
+-------+
| /|\
| |
LOCAL | | LOCAL
| |
\|/ |
+--------+/_________________
| Middle |\______________ |
+--------+ | |
| /|\ INTERNET | |
| | | | INTERNET
INTERNET | | INTERNET | |
| | | |
\|/ | \|/ |
LOCAL +--------+ +--------+ LOCAL
_____________\| Middle | | Middle |/_____________
| /+--------+ +--------+\ |
| / \ |
| LOCAL / \ LOCAL |
| / \ |
|___+-----+/_/ \_\+-----+___|
| |\ /| |
| Back|____________________________________\|Back |
| | ANY PROTOCOL /| |
+-----+ +-----+
So, does this mean a remote middle is 'contacted' 2 different ways by the local
middle (data comes directly from backend, but the local middle tells the remote
middle that the data is coming)?
And what if the data flows onward to a 3rd back-end? I don't have room to draw
that :-)
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 25 19:50:35 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] command-line composite (was: Attempt at Constructing the Command Line)
References: <3883D320.4594BBD2@geoserve.net>
Message-ID: <38B7235B.B719ABF4@geoserve.net>
A long time ago, in a galaxy far, far away "J.W. Bizzaro" wrote:
>
> Brad Chapman wrote:
> >
> > 3. Right click and add a "composite" widget to the workspace
>
> I was wondering why the composite locus was needed, but then I realized that
> you were planning on executing the composite as a whole.
>
> Of course, scripts/WFD's should be executable without first being composited.
> Is that what the 'execute script' option is for?
>
> Scripts/WFD's should be compositable at any point: The first step need not be
> to make a composite.
Brad, I was wrong about this, and you were right.
Recall that command-line loci (executable name, flags, filenames, etc.) are
connected via 'string-adding' connectors. Well, considering ordinary 'loci' by
definition can be anywhere on the Internet, it doesn't make sense to consider
these command-line loci ordinary. The problem is, how would you do
'string-adding' across the Internet? And does it even make sense to try it,
because these loci are soooo simple.
So, I propose that we define a special locus/widget that is like a composite
locus but contains only command-line loci.
Going back to our old example (where I was beginning to see the need to
separate these special loci) we have a 'command-line composite locus':
+----------+
----->(1)| |(3)<------
(2)<------| x-povray |(4)<------
| |
+--------------------------+----------+----------------------------+
| | (2) | | |
| | /|\ | | |
| \|/ | \|/ \|/ |
| (1) | (3) (4) |
|+-----------+ +------+ +---------+ +---------+ |
|| processor | ---> | flag | -----> | infile | -----> | infile | |
|+-----------+ +------+ +---------+ +---------+ |
|| x-povray | | -I | |
|+-----------+ +------+ |
+------------------------------------------------------------------+
(1) & (2) are workflow I/O using command-line stdin/stdout.
(3) & (4) provide the command line with the local (UNIX commands
work with local files) location of the input files.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Fri Feb 25 23:50:01 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] command-line composite (was: Attempt at Constructing the
Command Line)
References: <3883D320.4594BBD2@geoserve.net> <38B7235B.B719ABF4@geoserve.net>
Message-ID: <38B75B79.F52A9146@geoserve.net>
> Going back to our old example (where I was beginning to see the need to
> separate these special loci) we have a 'command-line composite locus':
I think we just nailed down the standard 'processor' type locus. This is it.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From chapmanb at arches.uga.edu Sun Feb 27 10:37:54 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] http protocol
Message-ID: <200002271541.KAA82678@archa11.cc.uga.edu>
> Well, you just hit on something I knew we would have to deal with.
The
>script 'loci' in the root directory should be a command-line program
that
>launches the fronts and middle as separate processes. Right now, it
has
>some Gnome stuff in it, which it should NOT. This is a left-over
from
>before our change in directory structure.
>
> Don't worry about making the 'loci' script work right, Brad. I want
to add
> that to my personal TODO.
Okee dokee, I'm not going to complain! It's all you, baby.
> I wouldn't characterize Loci's brokerage of different communications
> protocols
> as being front-to-middle communication.
You're right, front-to-middle only on the same computer. Gotcha!
> Here's a flowchart:
[..snip..]
I *think* I am on the same page with you since my hand-drawn
"Loci communications diagram" that I am trying to work off looks very
similar to what you were diagramming, only a lot more ugly. We should
try and make sure everyone is still in agreement on how things should
go once we start to implement different protocols. For now, the
front-to-middle communication is all I'm working on, and we'll have to
worry about other stuff as it comes.
I just cvsed more of the changes towards complete separation
between front and middle. The streaming dialog model is implemented
for locus addition and connection, and all of the talking occurs
through a port on the localhost, so from as far as I know security
should not be a problem with this (unless someone already hacked your
machine). There is a pretty weak communication log starting to be
implemented, and the front now waits for a response from the middle,
processes the response, and then does stuff with it (thanks for the
Expect code--that was a big help!). This is just barely tested to
work, and more will be coming (but after I spend some time with cactus
and exams(ugh!)).
Hopefully all of my ugly code will be out of the front soon so
that Jeff can work his magic on it!
>Plea: Guys, for the sake of simplicity (and security!) can we just
deal with
>_one_ Internet connection (between middles)? At least until we've
got this
>stuff down to a science. What do you say?
Definately! 100% with you!
>The 'INTERNET' connection is something we haven't discussed at all.
It
>involves 2 middles talking to each other. Of course it can be via
standard
>Internet socket. Some may argue for CORBA...I wouldn't ;-)
I'm going to definately agrue for corba pretty heavily on this, but I
think we should focus on local stuff first before we move into this.
There definately isn't enough infrastructure in the middle to deal
with middle to middle communications effectively now, so this is
something I'll work on. Then we can fight it out over this....
Brad
From chapmanb at arches.uga.edu Sun Feb 27 10:42:06 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:16 2006
Subject: [Pipet Devel] Line)loci] command-line composite (was: Attempt at Constructing the Command
Line)
Line)
Message-ID: <200002271545.KAA118806@archa10.cc.uga.edu>
Jeff wrote:
> So, I propose that we define a special locus/widget that is like a
composite
> locus but contains only command-line loci.
>
>I think we just nailed down the standard 'processor' type locus.
This is it.
I think this is a really good idea! With my junk I wasn't aiming at
this, but was rather thinking of using the composite locus to deal
with everything. However, I like your vision of having the standard
processor loci be a special case of a composite widget much better.
I'm looking forward to seeing it in action :-)
Brad
From bizzaro at geoserve.net Sun Feb 27 11:44:25 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] Line)loci] command-line composite (was: Attempt at
Constructing the CommandLine)Line)
References: <200002271545.KAA118806@archa10.cc.uga.edu>
Message-ID: <38B95469.3CBF61C1@geoserve.net>
Brad Chapman wrote:
>
> I think this is a really good idea! With my junk I wasn't aiming at
> this, but was rather thinking of using the composite locus to deal
> with everything. However, I like your vision of having the standard
> processor loci be a special case of a composite widget much better.
Right. And if you think about it, we're defining 'processors' as 'programs
that process the data', and all UNIX programs can be launched from the CLI
(many may not have CLI options, but they are still launchable from there). So,
the basic windowlet/UI for a processor should include a way to manipulate its
command-line. All UNIX programs, in fact, must work this way under Loci (and
probably fall under the locus type 'processor').
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sun Feb 27 12:14:11 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] http protocol
References: <200002271541.KAA82678@archa11.cc.uga.edu>
Message-ID: <38B95B63.EF0C11F0@geoserve.net>
Brad Chapman wrote:
>
> > Here's a flowchart:
> [..snip..]
>
> I *think* I am on the same page with you since my hand-drawn
> "Loci communications diagram" that I am trying to work off looks very
> similar to what you were diagramming, only a lot more ugly. We should
> try and make sure everyone is still in agreement on how things should
> go once we start to implement different protocols.
I'd like to fire up Dia to make some better-looking flowcharts. And these
should go into the documentation Gary is preparing, which will be shown to
everyone here so that we can get their approval.
> For now, the
> front-to-middle communication is all I'm working on, and we'll have to
> worry about other stuff as it comes.
That's fine. There's only so much a couple developers can do, and Loci is a
large project.
But I'm confident that once we make some usable releases, we'll catch a lot of
attention. I've seen a number of projects on the net go from a trickle to a
waterfall of activity. The most important thing in an open-source project,
IMHO, is that the developers stick to it. As soon as project development
appears dead, the whole project and its use is truly dead. People will move
on.
Speaking of usable releases, I think we should start planning for a 0.0.l
'alpha' release. I know there is a lot of debate about what makes a program
alpha quality. For example, Mozilla is only now considered alpha. Developers
often use 'pre-alpha' to mean "don't even think of using this for anything".
I, on the other hand, think pre-alpha is the 'conceptual stage' where
relatively little to no code has been written. Alpha is the 'initial coding
stage' where drastic changes can be made (perhaps we are already there). Beta
is the 'testing stage'. And after that you have your production releases.
So, I think
0.0.X is alpha
0.X is beta
X is production
And pre-alpha has no release number.
Okay, probably not even half of open-source developers would agree. But this
how I want to do it.
> I just cvsed more of the changes towards complete separation
> between front and middle. The streaming dialog model is implemented
> for locus addition and connection, and all of the talking occurs
> through a port on the localhost, so from as far as I know security
> should not be a problem with this (unless someone already hacked your
> machine). There is a pretty weak communication log starting to be
> implemented, and the front now waits for a response from the middle,
> processes the response, and then does stuff with it (thanks for the
> Expect code--that was a big help!).
Wow, that is really great!
> This is just barely tested to
> work, and more will be coming (but after I spend some time with cactus
> and exams(ugh!)).
Cactus?
> Hopefully all of my ugly code will be out of the front soon so
> that Jeff can work his magic on it!
Oh boy, oh boy!
> >Plea: Guys, for the sake of simplicity (and security!) can we just
> >deal with _one_ Internet connection (between middles)? At least
> >until we've got this stuff down to a science. What do you say?
>
> Definately! 100% with you!
And you, Gary?
> >The 'INTERNET' connection is something we haven't discussed at all.
> >It involves 2 middles talking to each other. Of course it can be
> >via standard Internet socket. Some may argue for CORBA...I
> >wouldn't ;-)
>
> I'm going to definately agrue for corba pretty heavily on this, but I
> think we should focus on local stuff first before we move into this.
Right.
> There definately isn't enough infrastructure in the middle to deal
> with middle to middle communications effectively now, so this is
> something I'll work on. Then we can fight it out over this....
I look forward to the battle ;-)
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sun Feb 27 12:20:05 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] http protocol
References: <200002271541.KAA82678@archa11.cc.uga.edu> <38B95B63.EF0C11F0@geoserve.net>
Message-ID: <38B95CC5.19EEAD4@geoserve.net>
"J.W. Bizzaro" wrote:
>
> 0.0.X is alpha
> 0.X is beta
> X is production
Oh yeah, and of course
X.Y where X > 0 and Y is odd, is development (beta)
X.Y where X > 0 and Y is even, is production
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sun Feb 27 13:06:51 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] new screenshot
Message-ID: <38B967BB.78379D1E@geoserve.net>
The first new screenshot in about 5 months:
http://bioinformatics.org/loci/documentation/screenshots/
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sun Feb 27 18:59:47 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] CHANGES; 20000227 J.W. Bizzaro
Message-ID: <38B9BA73.1CF4F1D6@geoserve.net>
20000227 J.W. Bizzaro
* Extracted code for Gnome GUI from main executable and put it in Gnome front
main.
* Added argument control of main executable so that Gnome front and middle can
be
started separately. Run
./loci middle
./loci gnome
in that order.
* Some name changes: gi->gnome, nli->natural, wi->web.
----------------------
Note that you have to kill loci middle manually.
This is all committed. Sorry Brad, if my changes interfered with yours :-P
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sun Feb 27 19:08:10 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] namespace
Message-ID: <38B9BC6A.F3499DA@geoserve.net>
I want to start naming every Loci class so that the name begins with 'Loci'.
I already made some changes to the code. For example,
WidgetMain() ---is now---> LociWidget()
Loci() (the Gnome GUI) ---is now---> LociGnome()
Get the idea?
Why do this? We are importing many, many modules in Loci. It's too likely
class names like Widget() or Gnome() are already used by PyGTK/GNOME. The same
is true for other modules.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From chapmanb at arches.uga.edu Sun Feb 27 19:35:08 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] CHANGES; 20000227 J.W. Bizzaro
Message-ID: <200002280038.TAA78228@archa10.cc.uga.edu>
.> * Added argument control of main executable so that Gnome front and
middle
> can
> be
> started separately. Run
>
> ./loci middle
> ./loci gnome
>
> in that order.
Cool. If you just type ./loci, will this fire up both at once?
> Note that you have to kill loci middle manually.
We should probably add stuff in so that we kill the middle
automatically when the front quits (should be no big deal--the middle
server has a shutdownNow variable). Stuff is still kind of messed up
right now becaue when the front quits it destroys the middles
directories--I still need to fix that when I work on more separation.
Brad
From chapmanb at arches.uga.edu Sun Feb 27 19:44:40 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] namespace
Message-ID: <200002280047.TAA159666@archa11.cc.uga.edu>
> I want to start naming every Loci class so that the name begins with
'Loci'.
I don't think we need to worry about this too much because of the
directory structure o' Loci. I think if anyone has another module in
their PYTHONPATH called middle.library.modules.xml.frontTalkHandlers,
then they *deserve* to have import problems. Plus, I don't see why
anyone would really need or want to import loci classes other than us,
and we can figure out if there will be problems.
So I think we should only do this where we forsee problems (ie.
Widget()) and not make it mandatory for all of the classes.
Also, I have been meaning to ask about how to work class and
function names (some people really care a lot about this issue). I
have been mostly using the lowerThenUpperCase type style for both
classes, modules and functions (and variables). However, I know some
people prefer lowerThenUpper for modules and classes and
lots_of_underscores for functions. The style guide is kind o
wishy-washy on this. Just curious if there were preferences...
Brad
From bizzaro at geoserve.net Sun Feb 27 20:06:24 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] CHANGES; 20000227 J.W. Bizzaro
References: <200002280038.TAA78228@archa10.cc.uga.edu>
Message-ID: <38B9CA10.B973C6B1@geoserve.net>
Brad Chapman wrote:
>
> Cool. If you just type ./loci, will this fire up both at once?
Err, no. I didn't make it so that it launches subprocesses. Running it 2
different times is what starts 2 different processes. I'll make improvements
to this later.
> We should probably add stuff in so that we kill the middle
> automatically when the front quits (should be no big deal--the middle
> server has a shutdownNow variable).
Yeah, I think we could have something like
loci --middle start
loci --middle stop
> Stuff is still kind of messed up
> right now becaue when the front quits it destroys the middles
> directories--I still need to fix that when I work on more separation.
Oh.
Say, why does the middle start 5 processes when run?
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Sun Feb 27 20:44:05 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] namespace
References: <200002280047.TAA159666@archa11.cc.uga.edu>
Message-ID: <38B9D2E5.E707CC5A@geoserve.net>
Brad Chapman wrote:
>
> I don't think we need to worry about this too much because of the
> directory structure o' Loci. I think if anyone has another module in
> their PYTHONPATH called middle.library.modules.xml.frontTalkHandlers,
> then they *deserve* to have import problems. Plus, I don't see why
> anyone would really need or want to import loci classes other than us,
> and we can figure out if there will be problems.
The problem is, if we use...
from middle.library.modules.xml.frontTalkHandlers import *
and you have a class named...
Print()
in the module, there is a good chance that using...
from othermodule1 import *
from othermodule2 import *
from othermodule3 import *
from othermodule4 import *
may also find a Print() class.
This is the problem with using an asterisk at the end of the import statement.
We could specify each class:
from middle.library.modules.xml.frontTalkHandlers import Print
which I think is very helpful for keeping track of where classes are called
from, and even for finding unused classes.
The only other way is to use...
import middle.library.modules.xml.frontTalkHandlers
The problem is, you are then required to put the module name at the beginning
of each class reference:
print = middle.library.modules.xml.frontTalkHandlers.Print()
Eh. Kind of long.
> Also, I have been meaning to ask about how to work class and
> function names (some people really care a lot about this issue). I
> have been mostly using the lowerThenUpperCase type style for both
> classes, modules and functions (and variables). However, I know some
> people prefer lowerThenUpper for modules and classes and
> lots_of_underscores for functions. The style guide is kind o
> wishy-washy on this. Just curious if there were preferences...
>From my understanding of the style guide, and how I have been writing Python
code...
modules --use--> alllowercasewithnospace.py
The exception to modules is if a module contains one class. Then...
modules --use--> CapitalizedWords (same as classes)
classes --use--> CapitalizedWords
methods --use--> all_lowercase_with_underscore
variables --use--> all_lowercase_with_underscore
or maybe
variables --use--> mixedCase ???
(the style guide doesn't say, but I like alllowercase)
constants --use--> ALL_CAPS_WITH_UNDERSCORE
(again, the guide doesn't say, but this is the C way)
I don't see anywhere that the mixedCase style is required.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Mon Feb 28 02:06:12 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] http protocol
References: <200002271541.KAA82678@archa11.cc.uga.edu> <38B95B63.EF0C11F0@geoserve.net>
Message-ID: <38BA1E64.E6E9960D@redpoll.pharmacy.ualberta.ca>
Been away visiting the relatives (Jane's in town), sorry for the
delay.
>
> > >Plea: Guys, for the sake of simplicity (and security!) can we just
> > >deal with _one_ Internet connection (between middles)? At least
> > >until we've got this stuff down to a science. What do you say?
> >
> > Definately! 100% with you!
>
> And you, Gary?
Absotively, 100%.
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From chapmanb at arches.uga.edu Mon Feb 28 07:10:16 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] Fwd: Bioperl: Pise release 5.a
Message-ID: <200002281213.HAA164064@archa10.cc.uga.edu>
Hey everyone;
This just came through on the bioperl mailing list. I just took a
quick look, but it is kind of scary--it seems like a lot of our ideas
are already being implemented here.
Brad
> Pise (Pasteur Institute Software Environment) is a program to
> generate Web interfaces for Molecular Biology programs. It has
> now run for 3 years at Pasteur and we have thought it could be
> useful to others.
>
> The Web page that describe Pise is located here:
> http://www.pasteur.fr/~letondal/Pise/
> The program is available here:
> ftp://ftp.pasteur.fr/pub/GenSoft/unix/misc/Pise.tar.gz
>
> The distribution and installation procedure has been greatly
improved
> thanks to the persons who have tried to install it. Many thanks to
them.
>
>
> --
> Catherine Letondal -- Pasteur Institute Computing Center
> =========== Bioperl Project Mailing List Message Footer =======
> Project URL: http://bio.perl.org/
> For info about how to (un)subscribe, where messages are archived,
etc:
> http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
> ====================================================================
From bizzaro at geoserve.net Mon Feb 28 09:00:27 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] Fwd: Bioperl: Pise release 5.a
References: <200002281213.HAA164064@archa10.cc.uga.edu>
Message-ID: <38BA7F7B.CF37A0DF@geoserve.net>
Brad Chapman wrote:
>
> This just came through on the bioperl mailing list. I just took a
> quick look, but it is kind of scary--it seems like a lot of our ideas
> are already being implemented here.
I don't recall having seen it. It is Web-based, of course. I've seen or heard
of programs like this, and I think Justin was working on one.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Mon Feb 28 10:22:58 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] improvements to main exe
Message-ID: <38BA92D2.D30DDBC6@geoserve.net>
I got the main executable to accept flags. The problem was Gnome kept trying
to read them. The solution is to read them before importing any module that
uses Gnome. There is a way to make use of Gnome's argument parsing, but it's
not in pygnome yet. Besides, Loci won't always use Gnome.
So, this is how you start Loci (copied from loci --help):
-----------------
Usage: loci [OPTION...] (for now, only one option at a time)
-m, --middle=STATE Run (STATE=on) middle or not (STATE=off)
-g, --gnome=STATE Run (STATE=on) gnome or not (STATE=off)
-?, --help Show this help message
--version Display version
Default: loci --middle=on --gnome=on
-----------------
So, just typing...
./loci
will start everything. Yes, the middle and front start together.
And if you want to start only the middle, type...
./loci -g=off
There is still a problem shutting down Loci. You will need to ^C or kill it.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From gvd at redpoll.pharmacy.ualberta.ca Mon Feb 28 10:33:06 2000
From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] Fwd: Bioperl: Pise release 5.a
References: <200002281213.HAA164064@archa10.cc.uga.edu> <38BA7F7B.CF37A0DF@geoserve.net>
Message-ID: <38BA9532.24BBEAB5@redpoll.pharmacy.ualberta.ca>
"J.W. Bizzaro" wrote:
>
> Brad Chapman wrote:
> >
> > This just came through on the bioperl mailing list. I just took a
> > quick look, but it is kind of scary--it seems like a lot of our ideas
> > are already being implemented here.
We'll have to add this one to the 'its so much like loci its scarey'
list. Pise looks like a good model for us to study when we imeplement
our own web-based interface to Loci. From my cursory rip through
throught the description, it differs from loci primarily in that the
data redirection (which is not well defined, so I could be off here),
seems simplistic. From what I can tell it is not network-distrituted,
simply piped. This implies that the processing applications reside on
the same machine. The piping appears step-wise. Consequently the
communications layer is not abstracted, and thus limited to command-line
programs. Loci's strength is in its generalized data-connectivity
brokering capability, so I don't see Pise as a 'threat' so much as a
'resource': Pise is GPL, so we are free to use it and study it, and It
does appear to have some very good design points (similar to applab in
many respects). I'd like to give it a try and maybe I can make some
more accurate/insightful commentary on Loci and Pise.
regards,
g.
--
Gary Van Domselaar
gary@bioinformatics.org
http://www.bioinformatics.org/~gary
----------------------------------------------------
bioinformatics.org: The Open Lab
http://www.bioinformatics.org/
From bizzaro at geoserve.net Mon Feb 28 10:59:58 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] snapshot tarball
Message-ID: <38BA9B7E.27E75A01@geoserve.net>
For those on the list who either don't have CVS access or can't figure it out
(most people), I made a tarball of the fresh, hot, steaming heap of code:
http://bioinformatics.org/loci/download/snapshots/loci-20000228.tar.gz
Enjoy.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From stein at fmnh.org Mon Feb 28 11:32:09 2000
From: stein at fmnh.org (Jennifer Steinbachs)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] Fwd: Bioperl: Pise release 5.a
In-Reply-To: <38BA9532.24BBEAB5@redpoll.pharmacy.ualberta.ca>
References: <200002281213.HAA164064@archa10.cc.uga.edu> <38BA7F7B.CF37A0DF@geoserve.net> <38BA9532.24BBEAB5@redpoll.pharmacy.ualberta.ca>
Message-ID: <200002281632.KAA12769@mail.fmnh.org>
I was in touch with the Pasteur group a few months ago
regarding Pise.
According to the admins at Pasteur (then), Pise simply
generates the HTML and CGI parts that are displayed at
http://bioweb.pasteur.fr. Since I haven't looked at the
new release, I cannot say if it has changed.
Bioweb runs on 3 DECalphas (2 duals), with a DEC queuing
system called LSF. They distinguish between 2 types of
access - internal and external. Internal jobs run with
an interactive priority while external jobs are limited
to a fixed number and run with a lower priority.
-j
------------------------
J. Steinbachs, PhD
Computational Biologist
Dept Botany
The Field Museum
Chicago, IL 60605-2496
312-665-7810
312-665-7158 (fax)
http://cb.fmnh.org
-------------------------
From mangalam at home.com Mon Feb 28 13:02:10 2000
From: mangalam at home.com (Harry Mangalam)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] Fwd: Bioperl: Pise release 5.a
References: <200002281213.HAA164064@archa10.cc.uga.edu> <38BA7F7B.CF37A0DF@geoserve.net> <38BA9532.24BBEAB5@redpoll.pharmacy.ualberta.ca>
Message-ID: <38BAB822.6BCA8352@home.com>
And in another take on this 'distributed/directed processing' model, the
omegahat project is an effort to move R (GPL'ed clone of S/Splus stats
modeling language) into this arena:
The omegahat software falls into three related but distinct areas:
1.an interactive environment, including language(s) and other tools, which
in its current form can be used as a way of programming with Java
interactively and which we hope will grow to provide new approaches to
statistical computing;
2.Java packages implementing methods of interest in statistical
applications (e.g. modeling, graphics, and simulation), or providing tools
that support the interactive environment (e.g., databases, parsing, task
management);
3.inter-system interfaces, currently providing access to Java from some
existing statistical systems and support for distributed statistical
computing through the use of the CORBA standard.
Anything sound familiar? :)
They also have a minimal implementation, so it may be valuable to peek at
what they have in more detail
Cheers
Harry
Gary Van Domselaar wrote:
>
> "J.W. Bizzaro" wrote:
> >
> > Brad Chapman wrote:
> > >
> > > This just came through on the bioperl mailing list. I just took a
> > > quick look, but it is kind of scary--it seems like a lot of our ideas
> > > are already being implemented here.
>
> We'll have to add this one to the 'its so much like loci its scarey'
> list. Pise looks like a good model for us to study when we imeplement
> our own web-based interface to Loci. From my cursory rip through
> throught the description, it differs from loci primarily in that the
> data redirection (which is not well defined, so I could be off here),
> seems simplistic. From what I can tell it is not network-distrituted,
> simply piped. This implies that the processing applications reside on
> the same machine. The piping appears step-wise. Consequently the
> communications layer is not abstracted, and thus limited to command-line
> programs. Loci's strength is in its generalized data-connectivity
> brokering capability, so I don't see Pise as a 'threat' so much as a
> 'resource': Pise is GPL, so we are free to use it and study it, and It
> does appear to have some very good design points (similar to applab in
> many respects). I'd like to give it a try and maybe I can make some
> more accurate/insightful commentary on Loci and Pise.
>
> regards,
>
> g.
> --
> Gary Van Domselaar
> gary@bioinformatics.org
> http://www.bioinformatics.org/~gary
> ----------------------------------------------------
> bioinformatics.org: The Open Lab
> http://www.bioinformatics.org/
>
> _______________________________________________
> pipet-devel maillist - pipet-devel@bioinformatics.org
> http://bioinformatics.org/mailman/listinfo/pipet-devel
--
Cheers,
Harry
Harry J Mangalam -- (949) 856 2847 -- mangalam@home.com
From David.Lapointe at umassmed.edu Tue Feb 29 11:19:32 2000
From: David.Lapointe at umassmed.edu (Lapointe, David)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] FW: Manipulate XML with Perl
Message-ID: <93307F07DE63D211B2F30000F808E9E50164502B@edunivexch02.umassmed.edu>
I know some ( most?) are on the Perl-XML list, so you saw this yesterday.
It would be interesting to try this with Python. The interaction with a
database was interesting to me.
David
FW: *---- *----
New article from developerWorks (http://www.ibm.com/developer/)
Manipulate XML with Perl
In this first tutorial of his series on using scripting
languages to manipulate and transform XML documents, Binary
Evolution's Parand Tony Daruger takes you through the first
steps of using these techniques with Perl. You'll see a method
for transforming XML to HTML, followed by a simple stock trading
application that uses Perl, XML, and a database to evaluate trading
rules. You can apply the techniques using other scripting languages
too, including Tcl and Python.
http://www-4.ibm.com/software/developer/library/xml-perl/?l=290,t=g,p=xmlper
l
---
You are currently subscribed to perl-xml as: [david.lapointe@umassmed.edu]
To unsubscribe, forward this message to
leave-perl-xml-65677R@lyris.ActiveState.com
For non-automated Mailing List support, send email to
ListHelp@ActiveState.com
From bizzaro at geoserve.net Tue Feb 29 15:10:57 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] we're back
Message-ID: <38BC27D1.44BBE51A@geoserve.net>
Brad and I started discussing some issues off of the list, but we'll move the
conversation back here.
This is what we discussed and decided:
First, some minor/silly stuff:
(1) Text case in Python scripts:
Modules, methods and variables will use lowercase_with_underscores.
Classes will use InitialCaps.
(2) We'll probably stick with tabs over 4 spaces for indentation.
Some more serious issues:
(3) We think the fronts (Gnome, Web, etc.) should be able to start and
stop the respective middles.
So, (Brad) we have to consider...
(a) Fronts and middles need to be initialized together. The
user cannot plug a front into a middle that has already
begun building a workflow diagram (at least for now).
(b) Since the Web interface will start multiple middles (one
per Web user), fronts need to know which middle it is
plugged into.
(4) The main executable will only process arguments on the command-line
and start fronts. It doesn't make sense to start a middle with no
front anyway.
I'm thinking that this main executable will start a front with an
argument like this:
./loci -g=on --geometry=100x100
and the arguments following one to start a front (-g=on) and
preceding one to start another, will be passed to the respective
front. So,
./loci -g=on --geometry=100x100 -n=on --no-comments
will pass -geometry=100x100 to the Gnome front and --no-comments
to the natural language front.
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Tue Feb 29 15:35:58 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] we're back
References: <38BC27D1.44BBE51A@geoserve.net>
Message-ID: <38BC2DAE.9FDA8E3B@geoserve.net>
"J.W. Bizzaro" wrote:
>
> and the arguments following one to start a front (-g=on) and
> preceding one to start another, will be passed to the respective
> front. So,
>
> ./loci -g=on --geometry=100x100 -n=on --no-comments
Or maybe running...
./loci
will, indirectly and by default, start the Gnome and NLI (in an xterm) fronts,
which are executables too. And if the user wants to do something else, he/she
can start any of the fronts directly. IOW, to start just the Web interface the
user will have to...
cd front/web
./loci-web [OPTIONS...]
How does that sound?
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Tue Feb 29 15:44:33 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] finding the middle (was: we're back)
References: <38BC27D1.44BBE51A@geoserve.net>
Message-ID: <38BC2FB1.C3E733B1@geoserve.net>
"J.W. Bizzaro" wrote:
>
> (a) Fronts and middles need to be initialized together. The
> user cannot plug a front into a middle that has already
> begun building a workflow diagram (at least for now).
>
> (b) Since the Web interface will start multiple middles (one
> per Web user), fronts need to know which middle it is
> plugged into.
Okay, now how do you launch 3 separate processes (2 fronts and 1 middle) and
have them all find each other? And how do the fronts find the right middle if
there's more than 1 middle running?
Any suggestions?
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From chapmanb at arches.uga.edu Tue Feb 29 17:06:48 2000
From: chapmanb at arches.uga.edu (Brad Chapman)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] we're back
Message-ID: <200002292209.RAA134280@archa10.cc.uga.edu>
> (1) Text case in Python scripts:
>
> Modules, methods and variables will use
lowercase_with_underscores.
> Classes will use InitialCaps.
Isn't this against the style guide for module names? It seems like the
style guide says only allunderscores or FirstLetterCap style for
modules, and I don't remember ever seeing a distribution that used
underscores for module names. I don't really have a personal
preference, I just want:
1. To be consistent with what other people are using (so that people
will *want* to program on Loci and not be annoyed by the code).
2. Not to have to change again!
> (b) Since the Web interface will start multiple middles (one
> per Web user), fronts need to know which middle it is
> plugged into.
The way I designed (well, copied the design of) the middle, a single
middle can accept requests from multiple fronts. So we should never
need to start more than one middle. Although this isn't finished yet,
my plan was to have the middle start up a different directory to hold
the workflow xml for each front that starts up. So if you started 3
fronts on one middle (please don't try this yet :-), you would get
three directories:
middle/temp/front1/workspace1
middle/temp/front2/workspace1
middle/temp/front3/workspace1
Each directory would be manipulated separately by its respective
front. They will all communicate over one port on the localhost.
If you want one front to be able to manipulate another front, this
is much trickier. The way things work right now is that the middle is
basically the slave of the fronts. It patiently waits for the front to
call it, does whatever the front says, and then returns the
appropriate info to the front. The front only listens to the middle
when it is specifically waiting for a response. To have the front be
continually listening to the middle so it can be manipulated will take
more work (and more threads), and it will probably only be useful for
using the NLI/voice interface to manipulate a graphical front. So I
think it might be worthwhile to put this off a bit until things are
smoothed out with this communication method.
The way I'm going to try to get things to work right away is that:
1. Only 1 middle will run at a time (ie. if you try to start 2 the
second one will not start).
2. The middle can handle multiple fronts (ie. process their xml
separately).
3. If a front starts and there is no middle started, it will
automatically start a middle.
How does this sound?
Brad
From bizzaro at geoserve.net Tue Feb 29 18:02:55 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] we're back
References: <200002292209.RAA134280@archa10.cc.uga.edu>
Message-ID: <38BC501F.E341C63A@geoserve.net>
Brad Chapman wrote:
>
> > (1) Text case in Python scripts:
> >
> > Modules, methods and variables will use lowercase_with_underscores.
> > Classes will use InitialCaps.
>
> Isn't this against the style guide for module names? It seems like the
> style guide says only allunderscores
^^^
You mean alllowercase ;-)
> or FirstLetterCap style for
> modules, and I don't remember ever seeing a distribution that used
> underscores for module names.
You're right. I thought the style guide implied that using underscores would
be acceptable, but it doesn't actually say that. I was just thinking it would
be easier to remember 2 styles than several. When in doubt, we should simply
read the style guide:
http://www.python.org/doc/essays/styleguide.html
> > (b) Since the Web interface will start multiple middles (one
> > per Web user), fronts need to know which middle it is
> > plugged into.
>
> The way I designed (well, copied the design of) the middle, a single
> middle can accept requests from multiple fronts. So we should never
> need to start more than one middle.
I meant 'one middle per Web front'.
> Although this isn't finished yet,
> my plan was to have the middle start up a different directory to hold
> the workflow xml for each front that starts up. So if you started 3
> fronts on one middle (please don't try this yet :-), you would get
> three directories:
>
> middle/temp/front1/workspace1
> middle/temp/front2/workspace1
> middle/temp/front3/workspace1
Okay, I guess you're talking about different 'sessions' and not about multiple
fronts tapping into one session. If this is so, perhaps you should have...
middle/temp/session1/workspace1
middle/temp/session2/workspace1
middle/temp/session3/workspace1
and one port per session.
> Each directory would be manipulated separately by its respective
> front. They will all communicate over one port on the localhost.
My idea for multiple fronts 'listening' or 'tapping' into a single session,
allowed one front to control others. If you're talking about multiple
sessions, shouldn't each session have its own port?
> If you want one front to be able to manipulate another front, this
> is much trickier.
I guess you're about to answer my question ;-)
> The way things work right now is that the middle is
> basically the slave of the fronts. It patiently waits for the front to
> call it, does whatever the front says, and then returns the
> appropriate info to the front. The front only listens to the middle
> when it is specifically waiting for a response.
Okay, so the front remains locked up while waiting for a response.
> To have the front be
> continually listening to the middle so it can be manipulated will take
> more work (and more threads), and it will probably only be useful for
> using the NLI/voice interface to manipulate a graphical front.
It'd also be neat to have a gnome front manipulated by someone using Loci
through the web/web-interface.
> So I
> think it might be worthwhile to put this off a bit until things are
> smoothed out with this communication method.
Okay. But what we're talking about is running the gnome front's GUI and
listening routine as separate threads. I think it should be done this way, so
that we can have one front manipulated by others.
And I think you're talking about multiple sessions with one middle. But which
would be more complex: one middle running multiple sessions or multiple middles
with one session each? Multiple middles would give us the problem I mentioned
of the front (not) knowing which middle to choose.
> The way I'm going to try to get things to work right away is that:
>
> 1. Only 1 middle will run at a time (ie. if you try to start 2 the
> second one will not start).
Okay.
> 2. The middle can handle multiple fronts (ie. process their xml
> separately).
Multiple 'sessions'? :-)
> 3. If a front starts and there is no middle started, it will
> automatically start a middle.
Uh-huh.
> How does this sound?
It sounds like a plan to me!
Cheers.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+
From bizzaro at geoserve.net Tue Feb 29 18:47:59 2000
From: bizzaro at geoserve.net (J.W. Bizzaro)
Date: Fri Feb 10 19:19:17 2006
Subject: [Pipet Devel] processes
Message-ID: <38BC5AAF.D9412AA2@geoserve.net>
(moved to the list)
Brad Chapman wrote:
>
> I get the following
> when I start *both* the front and the middle.
>
> chapmanb 23673 0.0 3.9 3244 2392 p2 S 4:40PM 0:00.31 python
> chapmanb 23675 0.0 11.3 9364 7004 p2 S 4:40PM 0:01.57 python
>
> If I just start the middle, I only get one process. I'm not sure why
> we are seeing a difference, I'm not getting anything unusual.
Okay, I did a cvs update because I thought that might be causing the
difference. Now this is what I find for processes running:
-----------------
jeff 7656 7.7 3.9 3232 2500 pts/3 S 17:20 0:01 python ./loci
-g=off
jeff 7658 31.0 9.6 8568 6056 pts/3 S 17:20 0:04 python ./loci
-m=off
jeff 7659 0.0 3.9 3232 2500 pts/3 S 17:20 0:00 python ./loci
-g=off
jeff 7660 0.0 3.9 3232 2500 pts/3 S 17:20 0:00 python ./loci
-g=off
jeff 7661 0.0 3.9 3232 2500 pts/3 S 17:20 0:00 python ./loci
-g=off
jeff 7662 6.5 3.9 3232 2500 pts/3 S 17:20 0:00 python ./loci
-g=off
-----------------
Note that the options show I have 1 gnome front and 5 middles running.
Also, shutting down the gnome front did not shut down the middles. But a kill
to any of the middles kills all 5.
Jeff
--
+----------------------------------+
| J.W. Bizzaro |
| |
| http://bioinformatics.org/~jeff/ |
| |
| BIOINFORMATICS.ORG |
| The Open Lab |
| |
| http://bioinformatics.org/ |
+----------------------------------+