[Pipet Devel] hierarchy (was: icons)

[J.W. Bizzaro]

"J.W. Bizzaro" wrote:
> 
> Question:
> 
>     Exactly WHAT can a /BL/ network/subnet contain?
> 
>         A. Only BL subnets and PL networks
>
>         B. Option A plus a couple nodes such as documents and
>            containers (as in the icon list)
>
>         C. Anything

>From the few comments I got back, it looks like Option A is what we should go
with.  IOW, BL and PL subnets are the only user-seen components that the BL
manages directly.  Option A might mean that we have 2 workspaces (networks): 1
BL workspace and 1 PL workspace, where PL workspaces are always contained
within BL workspaces.  This is what I thought we should have at first, but
after thinking about it for some time now, I think we can have something even
better.

I'll call it "Option A1": Like Option A, Option A1 makes the BL responsible
for only BL and PL subnets.  But, let's do something magical: Let's make BL
subnets INVISIBLE to the user!

Imagine using Pied with 2 types of workspaces (Option A above).  You start off
with a /BL/ workspace where you can add a node representing another BL
workspace, or a node representing a PL workspace.  Say, for example, you add a
node representing a PL workspace.  You open the windowlet, and there you
pretty much have Overflow (at some remote location) to work with.  But, how do
you connect 2 PL workspaces together?  It can only be done by connecting the
nodes that represent the PL workspaces, not from WITHIN the PL workspace.

Now, let's say we merge the 2 workspaces (or make the BL workspace transparent
to the user).  You start up Pied/Piper, and you essentially have a /PL/
(Overflow) workspace.  This is on your local host.  You start connecting all
sorts of PL nodes together and then decide, "Hey, it'd be nice if I could
connect to a PL node on Brad's computer".  So, you subscribe to Brad's
computer, find the node (or subnet) you want and place it on your /PL/
workspace.  Everything looks like Overflow operating locally, but Piper knows
where everything really resides.

Implementation shouldn't be difficult at all, since we are abstracting the
Build-Time Subsystem (even abstracting "View" and "Model" within the BTS) and
Run-Time Subsystem.  The user may think all nodes and subnets are local, but
Piper knows otherwise.

Comments?  This may be how some people envisioned Piper to begin with, but in
my mind, there were some competing models (options A, A1, B and C), and I
wasn't quite sure which would be best.

Cheers.
Jeff
-- 
                      +----------------------------------+
                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |
                      +----------------------------------+