"J.W. Bizzaro" wrote: > > About the architecture... what about this: Everything that's done locally > > (including running other exceutables) is handled by Overflow and all networking > > stuff would be handled by GMS, which would take care of connecting all Overflow > > processes (here I'm talking about "process" in a weak sense) through a network. > > This way there wouldn't be any duplication. Also, every node-to-node connection > > in the GMS part of the GUI would be assumed to be "network-able". > > This is EXACTLY what I was thinking of. Brad and Jarl, is this not what you > guys were thinking? I'll add my $cdn 0.02 here. This seems like the most sensible solution. Integrating Overflow and GMS this way allows the data to flow transparently, >and< preserves Overflow's speed-optimized data flow protocol. > > > Concerning the GUI, I don't think it would be hard to plug in what we've got so > > far in another app. Or we can just embed the current GUI in the new app using > > bonobo. I don't know enough about this to say which is best. > > I don't dislike Overflow's GUI. I just believe GMS and Overflow should have > GUIs that work alike. Plus, we've come up with some very nice GUI features > for Loci that I'd like to see VSH have. I agree. From the user's perspective, both GMS and Overflow behave alike; they should a common interface. That way, the end user need not be aware of which 'engine' is behind the interface, which is the way is should be. Regards, g. -- Gary Van Domselaar gary at bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/