[Pipet Devel] from Justin

[J.W. Bizzaro]

Justin Bradford wrote:

> I'm going to work a little late tongiht and start on the first
> implementation of the underlying loci infrastructure. Here's my plan:
> 
> 1. simple command-line digest program. feed it a peptide sequence (1
>    letter abreviations), and a digestion enzyme selected from a few
>    hardcoded in the program.

Great.  I was thinking that I could get Loci to wrap a GUI around "ls", as a
test ;-)

> 
> 2. python wrapper from paos object to 1 and back, merged with paos server

I'm at the point in the WFD (Work Flow Diagram) where I need to communicate with
a server, so I need to get into PAOS.

> 
> 3. merged paos server and client, combined with a mini tool address book.

What do you have in mind for the tool address book?  Right now the WFD uses this
generic block of code to define a locus:

--------8<--------
        locus1 = Locus()
        locus1.first = locus0
        locus1.parent = locus0
        locus1.group = locus1.parent.group.add('group')
        locus1.type = 'Widget'
        locus1.label = 'This is locus 1'
        from testwidget1 import *
        locus1.gui = TestWidget1()
        locus1.x = 100
        locus1.y = 10
        locus1.placed_x = locus1.x
        locus1.placed_y = locus1.y
        self.add_locus(locus1)
--------8<--------

locus.first is the root canvas group, and .parent and .group help define the
placement in the hierarchy.  We do need to have each locus identify its type and
label/name.

Next, the actual GUI for the locus is "imported", which in the case of the
command-line program is a concatonation of GUI XML's that will help construct
the command-line.  Since a locus is a concatonation, I need to make a generic
XML parser / GUI displayer, which really comes from "pyglade" by James
Henstridge.

x and y  placement is not specified by the locus but is determined by the WFD. 
I'm working on it.

> 
> 4. paos client with simple text interface to allow entering a peptide
>    sequence and an enzyme name, as well as outputing a list of digested
>    fragments.

Probably a GtkText widget?

> 
> 2 and 3 will then run on their own ports as daemons.

Good point.  I realized that the Loci server will have to run as a daemon, just
like a Web server.  This is because signals can come from many places at any
time.  How about "locid" for Loci-daemon?  I suppose the daemon can include the
tool address book?  I'm looking for one program that everything can call on for
services.

> 
> a user starts up 4, types in the seq/enzyme.
> 4 makes an object with entered data, and connected to 3
> 3 accepts object from 4, and looks at destination/tool property.
> if dest/tool prop. is a specific network address, have the client aspect
> of 3 contact 2. if a generic tool, consult address book to find
> appropriate address, then contact 2

I'm thinking that the deamon is the same program on the local and remote
machines.  They both have address books of what loci/tools are local to them. 
But when the local daemon contacts the remote daemon, it downloads the remote
daemon's address book.  So the local daemon acts as if EVERYTHING is local.

> 2 accepts the object from 3, formats the data so 1 can use it.
> run 1, and 2 takes output, stores in object.
> 2 then updates 3, and 3 then updates 4.
> 4 outputs the data.
> 
> I already have a number of things I want to change, but I'll just build
> that first. Then, we have to decide how the network layer will work,
> and how to abstract objects (particularly XML) and how they are
> transferred.

Yep.  Good.

> I actually have quite a bit of free-time now with school out, so once I
> have a home network connection again, I hope to get a lot of the lowlevel
> loci done this summer.

Yeah, I have a lot of time to spend on Loci.  Well, that is if I don't want to
get my Master's by August ;-)  BTW, I switched from the Ph.D. to the Master's at
BC because I want to get into a more compuational grad program...on a personal
note.

> I'm on the xml-mol list, which is also rather
> silent. Hopefully we can hash out the DTD's for our various datatypes
> soon.

So I take it you saw my little debate about the uses of XML?  Any thoughts? 
Again, I think most people have one big app in mind when they're talking about
XML: the Web browser.  In all fairness, XML was adopted by the W3C for the Web,
but I think it is suitable as a simpler offspring of SGML.


:-)
Jeff
-- 
J.W. Bizzaro                  mailto:bizzaro at bc.edu
Boston College Chemistry      http://www.uml.edu/Dept/Chem/Bizzaro/
--