> I'd like it to work as much like the Unix shell/CLI as possible. So, hitting > return on a blank line should give you another prompt. I think I can do that just by redefining what "" does on input. > Interesting. I was thinking about a non-interactive, all-in-one command > like... > > nodeset number=1 type=1 ip=121.0.0.0 > > But command-lines like this are hard to remember. How about we combine the > two: If the user enters an incomplete command, Peep asks for the extra values? Pretty easy to do. I was thinking of that too...I'm an inpatient user, and I hate prompts...I love command line stuff. But I figured it would also order the process a bit more if that ability was there. I'll write that in. > > Okay, maybe this is just a test/example, but node numbering should be > automatic...probably handled by the UI (not the DL). *nods*...the UI probably should hand it off. The numbering part is easy enough. I'll just assign a list of loci. Editing a large stack of loci after they're built won't be too hard in python, looks like, since dictionary data types are mutable and searchable. Did I mention I really love python? :) > > > Enter new node type: type2 > > Enter the remote IP or name for this node: 121.00.00.01 > > These two are really for specifying a BRAND NEW node, and I'm not sure how > much or if that will be needed. Piper should know what is on the local > filesystem and any remote systems you're connected to. The user should be > able to type a "list" command to see all basic nodes available and all > pre-prepared networks. Yup. This was just a test case, to figure out how stuff works. I can have a command in peep to add to the network list, too, as part of the UI. As a user, I'd like to see that functionality in peep so I don't have to leave peep to define new loci. Is there a central datafile (I guess this is for Brad) with loci lists and local network lists? > I think the only time the user will need to enter an IP is to link with a > Piper on another, known system. *nods* THat could be a submenu entry, then. > > Yeah, this is what I was thinking about. It's something like the ls command, > aint it? Yup. Peep will probably be pulling this stuff from the ls subroutine. I was just playing with learning how to select out dictionary entries. :) > > If the UI would simply assign a number (dynamically -- if a locus is removed, > everything is renumbered) to each locus:pipe in the network, it'd be a lot > easier on the user. So, if... > > piper://bioinformatics.org:1000/unix/commands/ls = 1 > piper://bioinformatics.org:1000/unix/commands/ls = 2 > > and > > out1pipe = C > in1pipe = A (attached to different loci, actually) > > the user can type... > > connect 1:C 2:A > > Simple. Yup, but that sounds even longer than I personally would like as a user. How about a configuration file somewhere that has those definitions in it, maybe indexed by locus nickname, and the user can select from a list they get with "config list" or something, like... <peep> job1 target testing.file <peep> config list Nickname Process Type ---------------------------------------------------- bioinf_ls piper:// bioinformatics.org:1000/unix/commands/ls density_ls piper://density.biop.umich.edu:1000/unix/commands/ls bioinfo_ps piper://bioinformatics.org:1000/unix/commands/ps density_gcg piper://density.biop.umich.edu:1000/usr/local/gcg <options> bioinf_psc piper://bioinformatics.org:1000/usr/local/psc <options> density_rpl piper://density.biop.umich.edu:1000/usr/local/perl/r.pl <file> <peep> job initiate testing testing.file Intializing job named "testing" with input data "testing.file" <peep> testing loci1 density_gcg -> bioinf_psc -align_center <peep> testing loci2 -> density_rpl <peep> testing loci3 -> density_ls (etc) <peep> loci map testing Job: Testing Locus:A Input Pipe: density.biop.umich.edu:1000/usr/local/gcg Output Pipe: bioinformatics.org:1000/unix/commands/psc -align center Locus:B (etc)