[Pipet Devel] from Justin

[Justin Bradford]

> > I'm going to work a little late tongiht and start on the first
> > implementation of the underlying loci infrastructure. Here's my plan:

Well, paos is giving me problems. I can't seem to get clients to
communicate to each other via a server. I'm starting some deeper
debugging to figure out what's going on.

> > 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.

We've never really settled the details of "inter-node" communication,
which I talk about at the bottom.

> 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:

I was just thinking concept. I haven't gotten down to any details.
However, my rant on DOM below does concern the method of storing this data
in a python object.

> We do need to have each locus identify its type and
> label/name.

Probably version, too, so we know what capabilities are available.

> 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.

I agree. It's a useful way to express things.

However, I've been thinking about how to express XML data in python.
I was thinking about using lists to make a DOM like structure. There are
already DOM tools for python, but they use classes which I (and many of
the authors) think are too much overhead for a DOM tree. They've proposed
rewriting the module in C and as lists, too.

data.doc = [NODE, 'dna',  
               [NODE, 'sequence',
                [ATTR, 'source', 'strain 4'],
                [DATA, 'ATGGGTCAAGTCCAATGATCCAGTAGTAAGCCAGTT'],
                ...
               ]
              ]

A DOM interface can be built on this easily, and normal python code can
access it directly, or use the DOM interface. A SAX interface could also
be done.

The benefit is that individual node/tools/components/etc don't ever have 
to worry about parsing XML and making up their own structures to hold
it. They always get these interfaces. Plus it will make it easy to export
interfaces (via CORBA or some simpler plug-in interface).

Paos could also be modified to use a DOM->XML module rather than pickle
for storage (and even transport). Furthermore, it would make it simpler
(possible?) for non-python nodes to communicate in the system.
Additionally, we could move to a providing an interface over the network,
rather than transferring whole objects. DOM over CORBA, DOM over IP, etc.

I know this is much more complicated than just using normal Python
structures for simple things, but it will be necessary to be able to
express arbitrary XML in a Python object.

Also, we can take advantage of Python to make these things more versatile.
For instance we could have:
obj1.doc = [NODE, 'foo',
            [NODE, 'bar',
             [OBJECT, obj2],    # a reference to another python object
            ]
           ]

obj2.doc = [NODE, 'stuff',
            [DATA, 'zxzxzxzxzxzx'],
            ....
           ]
           

Plus, Paos can keep track of these things automatically, and we could do
things like only send a part of the whole across the network.

I might make up a quick DOM interface, and try this out in the test model
I described early (once it's running of course).

Thoughts? 

Justin