[Pipet Devel] Brad: I've got a little task for you

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> Note that since this now does XML parsing, loci-file requires something
> new. I used the SAX (simple API for XML) complient parser from the python
> xml toolkit.

The licenses are acceptable.  I'd like to keep the number of extra packages
that the user needs to install to a minimum though.  Does SAX provide what
straight xmllib cannot?

> You can get the toolkit by going to:
> http://www.python.org/topics/xml/download.html. The newest version is
> PyXML-0.5.2.tar.gz, but I couldn't get this to install for me, so I am
> using PyXML-0.5.1.

There is no rule for 'make install' in 0.5.2.

I just copied xml/ to /usr/lib/python1.5/site-packages/ after 'make'.

> Sorry I had to go above this. I couldn't figure enough out from xmlparse.py
> to know how to work this lib, and there is some pretty helpful
> documentation on the SAX stuff. I'm not sure about all the differences, but
> if necessary I can probably scale back later not to use the XML toolkit.

SAX actually includes a modified version of xmllib, so if SAX is well
documented, you may find xmllib docs there too.

> Well, give all the credit for the recursive descending to the writers of
> os.path.walk(), not me! The reason I did this is for flexibility. I would
> really like to represent the contents of a container as a tree, instead of
> a list (hence the two widgets) so that a user can look into subdirectories
> to see what is there, without having to create a new container.

It's certainly more convenient than openning up new containers.  But since
containers can represent large databases, it wouldn't be a good idea to use
trees everywhere.

BTW, It looks good, Brad.  Nice work!

> I am having
> trouble parsing the XML into a tree, so I can't demo this yet, but I'll
> keep working on it. Even with the recursive descending, it is no problem to
> display the info as a list. I would be interested to hear people's thoughts
> on the tree vs. list representations.

I wonder about speed:

    1. Recursively descend a directory (of any size and at any _location_).

    2. Write to XML.

    3. Create tree widget.

    4. Parse the XML and put into tree.

How long would it take to do this for a large filesystem? at a remote
location?

These are the reasons why I wanted to use a list.  If trees are (1) made fast
enough and (2) aren't used for every container, they would be good to use. 
Can you give us some feedback about these issues?

> I will definately do this next time. I tried to use the command 'cvs add
> loci-file', which, according to the book "Open Source Development with
> CVS", *should* allow me to add a directory, but this gives something like
> the following error:
> 
> cvs add: in directory .:
> cvs [add aborted]: there is no version here: do 'cvs checkout' first
> 
> Any ideas why that is?

loci-file was the module, and modules need to be made using

    cvs import (etc.)

>from _within_ loci-file, you can add directories using

    cvs add <directory>

after having made the directory in the filesystem.

> That is the picture I was imagining. If we are following the Apache model,
> there are no opportunites for outside users to reach any directories
> besides those inside $LOCI_ROOT. Same with ftp servers, right? I'm not
> positive how to do this, but it seems definately possible!

Yeah, anonymous ftp is a good example too.  You can going anywhere in the
filesystem with ftp providing you log in with an account.  Anonymous users are
limited in where they can go.


Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |           THE OPEN LAB           |
                      |    Open Source Bioinformatics    |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+