[Pipet Devel] Gnome stuff

[J.W. Bizzaro]

Brad Chapman wrote:
> 
> So, bonobo is just for embedding a component of one
> program inside the container of another program. Okay.

Right, and I think only GUI components.

> Okay--will this be stored directly in the XML representing the workspace
> graphical script? For instance if we had a container representation like
> the following:
[cut]
>  <location>/usr/local/loci/workspace</location>

But since the network is transparent to Loci, all <locations>s have a URI. 
So, the above location would be something like this:

    <location>locus://localhost/</location>

where

    /usr/local/loci/

Is the root directory for Loci.

***JUST USE APACHE AS AN EXAMPLE***

    /home/httpd/html/

Is the root directory for Apache Web pages (on RedHat), and this is given the
URI/URL

    http://localhost/

Note that Apache can access _local_ directories using the same URL mechanism
for _remote_ access.  THIS IS HOW LOCI WILL WORK.

Perhaps Loci's root should be

    /home/loci/

(I can see we'll get some arguments about this from BSD users :-))

>  <container>
>    <name>my_seq_files</name>
>    <location>/usr/home/chapmanb/my_seq_files</location>
> 
>    <file>
>     <name>gb_file_1.gb</name>
>    </file>
> 
>    <file>
>     <name>gb_file_2.gb</name>
>    </file>
> 
>    <container>
>     <name>fasta_files</name>
>     ...the contents of the directory
>    </container>
> 
>    <container>
>     <name>phylip_files</name>
>     ...the contents of the directory
>    </container>
>  </container>
> </container>

Right.  When the container locus is made, all of the XML is generated,
including that of the windowlet contents, which in the case of a container, is
the _directory_ contents.

> If /usr/local/loci/workspace is where everything is analagous to the root
> directory in a web server, this is where the "Loci filesystem" starts.

You're correct that Loci should not have access to '/'.  This would be a
security problem, especially when a container can point to (via URI) the
filesystem of a remote computer.  Maybe we should have 2 branches under Loci's
root directory:

    /home/loci/public/
    /home/loci/private/

Remote Loci can then only access what is in the public directory.

> Then
> if a user double clicks on the my_seq_files container icon, we would go
> through the XML to look for my_seq_files and find it at
> loci_root.my_seq_files, which would by default be located at
> /usr/local/loci/workspace/my_seq_files.

Yes.

> In this example, I figured that the
> user would probably have their sequence files located in some home
> directory and not on the loci filesystem (/usr/home/chapmanb/my_seq_files,
> in this example). So then we have something analagous to a symbolic link,
> with /usr/local/loci/workspace/my_seq_files ->
> /usr/home/chapmanb/my_seq_files. So my idea here is that the location of a
> file or directory would be with respect to the loci_root directory unless
> there is a <location> tag directly specifying to look elsewhere.

Good idea.  You get a star.

Regarding a user accessing things in his home directory, and even making some
things public, we can do what Apache does and have

    locus://bradcom.com/~brad/

point to

    /home/brad/loci/

and you would have

    /home/brad/loci/public/
    /home/brad/loci/private/
    /home/brad/loci/workspace/

too.

>         Anyways, is this along the lines of what people were thinking for
> the representation? I haven't really said anything about how to actually
> generate this kind of XML, but I just wanted to make sure I was on the
> right track!

You are correct, sir!

> Okay, so if in the above example I wanted to move gb_file_1.gb from the
> container to the main workspace, I would drag it into the workspace and in
> the real directory structure, the file would move from
> /usr/home/chapmanb/my_seq_files/gb_file_1.gb to
> /usr/local/loci/workspace/gb_file_1.gb? Do you want the file to actually
> move, or just to create a link to the file from inside the
> /usr/local/loci/workspace directory system?

Hmmmm.  I suppose the user can either 'copy' or 'move' something onto/from the
Workspace (and other areas) just like using a file manager (copy means the
original stays, and move means the original is deleted).  But I don't think
the user should be able to 'move' a file to/from a _remote_ system, so only
copying would be allowed in such a case.  I'd say that by default a DnD would
move a locus, unless it is remote (not on the local filesystem).

Keep in mind though, that when the user manipulates loci, he/she is only
manipulating an XML _representation_ of something that can exist anywhere on
the Internet (and is _always_ referenced to via URI).  Since that XML
representation should be small (about the size of a typical Web page), the
transfer of it should be trivial.  So, I wouldn't create symlinks but just
copy or move the XML representations.

The transfer of the actual program or data that the locus represents is
another case altogether.  I think this can be handled (in a GUI sense) via
pop-up menu option and not DnD.


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