From bizzaro at geoserve.net Sat Apr 1 11:00:44 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:27 2006 Subject: [Pipet Devel] alright, that does it! Message-ID: <38E61D2C.4BCD6A04@geoserve.net> Our e-mail addresses are obviously on some master spam list, so posting is now restricted to list members. My apologies. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Apr 1 11:25:00 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] alright, that does it! Message-ID: <200004011627.LAA154056@archa10.cc.uga.edu> > Our e-mail addresses are obviously on some master spam list, so posting is > now > restricted to list members. Jeff, I think the problem is actually with mailman. They are having similar problems with spam on the python lists, and it is apparently just some new spammer trick to get around mailman's defenses. To quote from a recent post from Andrew Kuchling on the Python XML SIG: > python.org mailing lists have been getting hit with more spam > recently. For example, this most recent spam sidesteps Mailman's spam > checking because it actually listed xml-sig@python.org in the To: > header. It was sent through an open relay in Japan (IP address > 210.136.121.2), though not one currently listed in the ORBS or RBL. > In any case, the fix is to improve the spam detection, whether in > Mailman or on python.org, and I'll talk to Barry about it. Closing > off the list is not a solution, particularly since we have > contributors who use several different e-mail addresses; I'm not going > to resort to that just yet. I, for one, would vote to keep the lists open and tolerate some spam until a solution is found. My 'd' key hasn't worn out yet :-) Brad From bizzaro at geoserve.net Sat Apr 1 11:57:12 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: alright, that does it! References: <38E61D2C.4BCD6A04@geoserve.net> Message-ID: <38E62A68.C8EA6DD5@geoserve.net> Well, then again, maybe not. Restricting posts to list members does not seem to work right on our system. For now, please bear with us and the spam until we figure something else out. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Sat Apr 1 12:23:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] CHANGES; as of 20000401 Message-ID: <38E63093.C13EA661@geoserve.net> 20000401 J.W. Bizzaro * Added 'window sill' (statusbar) to the windowlet class. * Window sill consists of 6 buttons: (1) Status symbol (needs to be button?) (2) Message (long button): show/hide message view Part of message appears on button. (3) View: network world, network normal, gui (4) Parent: window occupies parent/own window (5) Shade: window frame shown/hidden (6) Resize Only shade works now. Need to make icons for buttons. * Big improvements made to windowlet code. 3/29/00 Brad * Started working on the GUI for saving loci in permanent storage. * Added a new locus 'savecontainer' to the add locus menu. A good way to display the save container will need to be worked on. * Drags from the workspace into the savecontainer are supported, but this only works properly for documents right now. 3/28/00 Brad * Added support in the middle for saving of loci to a permanent storage directory and for retrieving the info from this directory. So far, this is completely untested (except that it doesn't have any glaring errors that get noticed on an import). 20000326 J.W. Bizzaro * Progress on workspace, locus and connector popup menus 3/25/00 Brad * Added disconnection of loci. There is a disconnect_locus function in the Workspace.py script which should allow for two loci to be disconnected without and issues in the middle. I've only tested this so far with disconnecting after deleting loci, but hopefully it will work for a general case. * Made a lot of fixes to how the middle stores connection info to handle the disconnection. Hopefully things are a lot better now. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From terri at fresnomail.com Sat Apr 1 06:59:00 2000 From: terri at fresnomail.com (terri@fresnomail.com) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Email Advertising Works--Special Rates till Friday Message-ID: <5hgo83i1fah11w0.010420000659@localhost> PUT EMAIL MARKETING TO WORK FOR YOU... Call NOW and receive 50,000 additional emails with your order for only $100. Thats 40,000 FREE emails!!! WE HAVE OPT-IN LISTS!!!! see below for removal. Special Ends Friday April 7, 2000 MLM'ers, We can build your downline. Imagine having a product or idea and selling it for only $10. Now imagine sending an ad for your product or idea to 25 million people! If you only get a 1/10 of 1% response you have just made $250,000!! You hear about people getting rich off the Internet everyday on TV, now is the perfect time for you to jump in on all the action. FACT. With the introduction of the Internet, one primary KEY to conducting your business successfully is creating massive exposure in a cost effective manner. FACT. The experts agree that email marketing is one of the most cost effective forms of promotion in existence today. Electronic mail has overtaken the telephone as the primary means of business communication.(American Management Association) Of online users 41 percent check their email daily. "A gold mine for those who can take advantage of bulk email programs"- The New York Times "Email is an incredible lead generation tool" -Crains Magazine "Blows away traditional Mailing"-Advertising Age "It's truly arrived. Email is the killer app so far in the online world"-Kate Delhagen, Forrester Research Analyst Why not let a professional company handle your direct email marketing efforts for you? *We will assist you in developing your entire campaign! *We can even create your ad or annoucement for you! *No responses? We resend at no cost! For More Information CALL NOW-702-248-1043 For removal see below. SPECIAL RATES SPECIAL ENDS Friday April 7, 2000 Targeted Rates Upon Request. BONUS!!! Call In and receive 50,000 Extra Emails at No Cost! Call NOW - 702-248-1043 ++++++++++++++++++++++++++++++++++++++++++++++++++ We are terribly sorry if you received this message in error. If you wish to be removed. Please, type "REMOVE" in the subject line: outnow@fiberia.com ++++++++++++++++++++++++++++++++++++++++++++++++++ From sharon at nfmail.com Sun Apr 2 14:33:56 2000 From: sharon at nfmail.com (sharon@nfmail.com) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Hear this! References: 071032AD2 Message-ID: <200004021441645.SM00350@localhost> FOLLOW ME TO FINANCIAL FREEDOM!! 1-888-217-0292 CALL NOW!! see below for remove. I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET-RICH-QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! ABOUT MAKING MONEY!!! CALL NOW 1-888-217-0292 DON'T GO TO SLEEP WITHOUT LISTENING TO THIS! "All our dreams can come true - if we have the courage to pursue them" -Walt Disney Please leave your name and number and best time to call. DO NOT respond by Email. We are trttibly sorry if you have received this message in error. If you wish to be removed. Please, type "REMOVE"in the subject line. frice@beijingoffice.com From rosa16 at pplmail.com Sun Apr 2 11:50:00 2000 From: rosa16 at pplmail.com (rosa16@pplmail.com) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Hear this! Message-ID: <200004021843.OAA03100@www.bioinformatics.org> FOLLOW ME TO FINANCIAL FREEDOM!! 1-888-217-0292 CALL NOW!! see below for remove. I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home! NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success! This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life! If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN! THIS IS NOT A GET-RICH-QUICK SCHEME! YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE! CALL ONLY IF YOU ARE SERIOUS! ABOUT MAKING MONEY!!! CALL NOW 1-888-217-0292 DON'T GO TO SLEEP WITHOUT LISTENING TO THIS! "All our dreams can come true - if we have the courage to pursue them" -Walt Disney Please leave your name and number and best time to call. DO NOT respond by Email. We are trttibly sorry if you have received this message in error. If you wish to be removed. Please, type "REMOVE"in the subject line. frice@beijingoffice.com From bizzaro at geoserve.net Tue Apr 4 06:01:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] window sill Message-ID: <38E9BD87.43F659AE@geoserve.net> I'm sorry that I've been too quite lately. I'll get back to some messages right away. You may have seen the 'window sill' mentioned on the Loci list. This is pretty much a status bar for the windowlets that appear in the workspace. Attached is a screenshot of one prototype window sill. Below is a description of window sill features and functions. There are 2 basic modes: Shaded and unshaded, which are just like window shading on the Mac and newer Unix WMs, only the BOTTOM of the window (the status bar) remains visible. The status bar is a leeetle bit more informative than the title bar of a window, right? Well, in the true nature of Loci (and now VSh), we're trying to rethink a lot of the 1981 Apple Lisa paradigms that people just can't see beyond. I've been thinking this over and over for days now, BTW. I believe this design gives us the most features for the least number of buttons present on the window sill: ------------------------------------- Unshaded mode: [OCCUPY] [VIEW] [RESIZE] Shaded mode: [INFO] [RESIZE] INFO * Visible only when window is shaded * Button contains a text message for each info item (not context-sensitive help) * Time elapsed while unprocessed * Unprocessed/processing/processed * Location * Help message for window's node (truncated) * (others) * INFO is for what occupies the window pane * Click button1 or button3 to cycle through messages (in different directions) * The only button to be horizontally expandable OCCUPY/UNOCCUPY * Click button1 to make self window pane occupy parent window * Click button3 to unoccupy self window pane from parent window * Window sill also occupies parent's (When I say 'parent', I mean a node that contains a network of nodes, one of which being the node in question.) VIEW * Click button1 or button3 to cycle through views: * GUI view: Gtk (composite) interface * Network normal: Network with icons, links and windows * Network world: Only links shown but for entire network (no scrolling needed). Single-click in workspace switches view back to network normal, focused in area of workspace where clicked (like a zoom feature) * Info view (all messages in single view): * Time elapsed while unprocessed * Unprocessed/processing/processed * Location * Help message for window's node * (others) * Context-sensitive help message: for ONE selected node in window's workspace, not for the window's node RESIZE * Press-drag button1 to resize * When shaded, only the window sill can be resized, and it's resized horizontally * Double-click to shade * Double-click again to unshade * OCCUPY and VIEW buttons not visible when shaded, because these pertain only to what occupies the window pane, which will not be shown * INFO is not visible when window is unshaded ------------------------------ I'd like you to note that NOT A SINGLE WINDOW SILL FEATURE OR FUNCTION CALLS ON THE MIDDLEWARE/CORE. THIS IS 100% GUI! And all of it with no more than 3 buttons visible at once! Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: button-test.xpm Type: image/x-xpixmap Size: 45105 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000404/93a99487/button-test.xpm From bizzaro at geoserve.net Tue Apr 4 08:35:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] window sill References: <38E9BD87.43F659AE@geoserve.net> Message-ID: <38E9E17D.F2D19D78@geoserve.net> "J.W. Bizzaro" wrote: > > INFO > * Visible only when window is shaded Brad mentioned to me that users would want to change the name of a node. Thinking about it a bit, the name is probably something we want to put under 'info'. So, maybe the INFO button can stay visible at all times and have the name as the first item. This way, we can remove the node name from under the icon and use just the INFO button. Thoughts? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 4 08:51:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: window sill References: <38E9BD87.43F659AE@geoserve.net> <38E9E17D.F2D19D78@geoserve.net> Message-ID: <38E9E55B.AAC03660@geoserve.net> "J.W. Bizzaro" wrote: > > So, maybe the INFO button can stay visible at all times and have the > name as the first item. This way, we can remove the node name from under the > icon and use just the INFO button. Maybe I will have the INFO button visible when the window is unshaded, but I think I'll keep the name on top with the icon. I don't want the name to disappear at any time. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Tue Apr 4 18:51:01 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: window sill Message-ID: <200004042253.SAA73000@archa10.cc.uga.edu> > You may have seen the 'window sill' mentioned on the Loci list. This is > pretty much a status bar for the windowlets that appear in the workspace. > Attached is a screenshot of one prototype window sill. I dig the window sill idea! Although I have no buisness saying anything about GUI design, I'll make a few comments below :-) > INFO > * Visible only when window is shaded > * Button contains a text message for each info item (not context-sensitive > help) > * Time elapsed while unprocessed > * Unprocessed/processing/processed > * Location > * Help message for window's node (truncated) Will the info button be replacing the "help" window thingy that I started using, or in addition to that? > OCCUPY/UNOCCUPY > * Click button1 to make self window pane occupy parent window > * Click button3 to unoccupy self window pane from parent window > * Window sill also occupies parent's > > (When I say 'parent', I mean a node that contains a network of nodes, one of > which being the node in question.) This is a really cool idea, but will the old windowlet with the network GUI get recycled by python memory collection if it gets popped out of a parent window? Just throwing that out, I really have no idea how memory collection works in pyGtk. Maybe it will still be fine as long as you maintain a reference to it. Also, I was having a lot of problems getting windows to refresh properly after resetting the contents of a windowlet... > VIEW > * Click button1 or button3 to cycle through views: > * GUI view: Gtk (composite) interface Can you describe this view? What does it look like? > * Network normal: Network with icons, links and windows Is this the view we currently have? > * Network world: Only links shown but for entire network (no scrolling > needed). Single-click in workspace switches view back to network > normal, focused in area of workspace where clicked (like a zoom > feature) Jeff, I was trying to play around with the canvas zoom feature as soon as I saw it was a feature, because I thought it would be a really cool thing to use. The GUI ended up really ugly for me because not everything scaled in the same way, especially the text box, if I remember correctly. > * Info view (all messages in single view): > * Time elapsed while unprocessed > * Unprocessed/processing/processed > * Location > * Help message for window's node > * (others) > * Context-sensitive help message: for ONE selected node in window's > workspace, not for the window's node How are the old views "stored"? For instance, if you have the view we have now, with links and windows and all that, will the view be exactly the same (ie. all the loci in the same places, all of the same windows open, etc) when you scroll back around to it? And again, I'm not positive if you'll see the refresh problem I couldn't fix. Just playing devil's advocate on all this stuff. The ideas are really cool, and I look forward to seeing them in action :-) Brad From bizzaro at geoserve.net Wed Apr 5 10:56:14 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: window sill References: <200004042253.SAA73000@archa10.cc.uga.edu> Message-ID: <38EB540E.457D71A@geoserve.net> Brad Chapman wrote: > > Will the info button be replacing the "help" window thingy that I > started using, or in addition to that? I want to define 2 types of 'help': One is a message about the particular node. The other, since a node can be made up of a network of nodes, is a message about the node SELECTED WITHIN the window of the node. This I would call 'context-sensitive help', since it will change according to the context. The Info button will contain only the first type of 'help' (for now). And the message will have to be truncated, since the Info button can be only so large. > > (When I say 'parent', I mean a node that contains a network of > > nodes, one of which being the node in question.) > > This is a really cool idea, but will the old windowlet with the > network GUI get recycled by python memory collection if it gets popped > out of a parent window? Just throwing that out, I really have no idea > how memory collection works in pyGtk. Maybe it will still be fine as > long as you maintain a reference to it. The Gtk object, that is the 'view' in the window, will not be thrown out. I can just use 'show' and 'hide'. > Also, I was having a lot of problems getting windows to refresh > properly after resetting the contents of a windowlet... Just now or a while ago? You mentioned this a couple months ago. > > * Click button1 or button3 to cycle through views: > > * GUI view: Gtk (composite) interface > > Can you describe this view? What does it look like? This is the composite GUI I keep yammering about. It contains Gtk widgets arranged according to the heirarchy of the network (if there is one) contained in the node. > > * Network normal: Network with icons, links and windows > > Is this the view we currently have? Yep. > Jeff, I was trying to play around with the canvas zoom feature as soon > as I saw it was a feature, because I thought it would be a really cool > thing to use. The GUI ended up really ugly for me because not > everything scaled in the same way, especially the text box, if I > remember correctly. I don't understand. You just tried to code this feature? What is the 'text box'? > How are the old views "stored"? For instance, if you have the view we > have now, with links and windows and all that, will the view be > exactly the same (ie. all the loci in the same places, all of the same > windows open, etc) when you scroll back around to it? As long as VSh (or the Gnome front) remains running, this information will not go away. The problem is when the program is shut down and restarted. If the user wants to reload a network, the middleware may have linkage information stored, but the front end will not have x/y positions stored...at least not now. We do need to come up with a way to store this user interface information. I most certainly don't want to MIX user interface information with the information the core needs, but we can keep it along side or parallel to the core information...perhaps as separate files. > And again, I'm not positive if you'll see the refresh problem I > couldn't fix. I haven't come across the problem, but I have heard mention of it on the Gnome lists. Apparently, we can force a refresh of the widgets. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Wed Apr 5 11:16:43 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: window sill In-Reply-To: <38EB540E.457D71A@geoserve.net> Message-ID: Brad wrote: > > Will the info button be replacing the "help" window thingy that I > > started using, or in addition to that? Jeff wrote: > I want to define 2 types of 'help': One is a message about the particular > node. The other, since a node can be made up of a network of nodes, is a > message about the node SELECTED WITHIN the window of the node. This I would > call 'context-sensitive help', since it will change according to the context. > > The Info button will contain only the first type of 'help' (for now). And the > message will have to be truncated, since the Info button can be only so large. That sounds very snazzy :-) > > > (When I say 'parent', I mean a node that contains a network of > > > nodes, one of which being the node in question.) > > > > This is a really cool idea, but will the old windowlet with the > > network GUI get recycled by python memory collection if it gets popped > > out of a parent window? Just throwing that out, I really have no idea > > how memory collection works in pyGtk. Maybe it will still be fine as > > long as you maintain a reference to it. > > The Gtk object, that is the 'view' in the window, will not be thrown out. I > can just use 'show' and 'hide'. Okay... I just thought you would have to remove a child window before you could insert another one in the windowlet. I thought you would get one of those wonderful gnome error messages about the parent node already having a child (since they can't have more than one, can they?). But then again, I might be smoking crack... > > Also, I was having a lot of problems getting windows to refresh > > properly after resetting the contents of a windowlet... > > Just now or a while ago? You mentioned this a couple months ago. Then, now, still, whenever. I never fixed it, I just had a stupid workaround by closing the window when I changed the windowlet, so they the user would have to open it back up and it would refresh automatically :-) Of course, this cheap hack won't work for your ideas. If you can make stuff refresh I would be so happy to learn how, because I tried calling all kinds of different refresh calls and couldn't get any of them to do anything for it. If you want to try it out, maybe you could try and make the main Loci window refresh after selecting a file (while it is waiting for the file info to come back from the definition layer). Right now it sits in a really ugly state (looking like it is locked up), and I couldn't seem to get a refresh to fix this, so I just had to give up before I spent my whole life on it. I am stuck :-< > > Can you describe this view? What does it look like? > > This is the composite GUI I keep yammering about. It contains Gtk widgets > arranged according to the heirarchy of the network (if there is one) contained > in the node. Is this what you are proposing will replace the GtkCTree view? Will be have to code our own widget for this? [...snip... my poor description of zoom...] > > I don't understand. You just tried to code this feature? What is the 'text > box'? I did code this feature, and then killed it because it sucked :-< There is a zoom command for the canvas which is supposed to provide "automatic" zooming, but I couldn't make it work. By the text box, I mean the little text thingy with the name of the widget (under the widget shape and little people picture :). > As long as VSh (or the Gnome front) remains running, this information will not > go away. The problem is when the program is shut down and restarted. If the > user wants to reload a network, the middleware may have linkage information > stored, but the front end will not have x/y positions stored...at least not > now. > > We do need to come up with a way to store this user interface information. I > most certainly don't want to MIX user interface information with the > information the core needs, but we can keep it along side or parallel to the > core information...perhaps as separate files. I see... I guess this is something that will have to come later on. Let me just stick with remembering one thing (the links) at a time :-) Brad From bizzaro at geoserve.net Wed Apr 5 11:34:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: window sill References: Message-ID: <38EB5CFA.CA5C117B@geoserve.net> Brad Chapman wrote: > > Okay... I just thought you would have to remove a child window before you > could insert another one in the windowlet. I thought you would get one of > those wonderful gnome error messages about the parent node already having > a child (since they can't have more than one, can they?). But then again, > I might be smoking crack... It depends on the container. I need to find one that will let me flip between overlapping children. The fixed-position and notebook containers come to mind. > Then, now, still, whenever. I never fixed it, I just had a stupid > workaround by closing the window when I changed the windowlet, so they the > user would have to open it back up and it would refresh automatically :-) > Of course, this cheap hack won't work for your ideas. If you can make > stuff refresh I would be so happy to learn how, because I tried calling > all kinds of different refresh calls and couldn't get any of them to do > anything for it. If you want to try it out, maybe you could try and make > the main Loci window refresh after selecting a file (while it is waiting > for the file info to come back from the definition layer). Right now it > sits in a really ugly state (looking like it is locked up), and I couldn't > seem to get a refresh to fix this, so I just had to give up before I spent > my whole life on it. I am stuck :-< Did you try a Gtk refresh or a canvas refresh? > > This is the composite GUI I keep yammering about. It contains Gtk widgets > > arranged according to the heirarchy of the network (if there is one) contained > > in the node. > > Is this what you are proposing will replace the GtkCTree view? Will be > have to code our own widget for this? No, I was suggesting to you that the 'view we have now' (the workspace normal view) replace the GtkCTree view for taking listings of directories. The composite GUI will look like a regular Gtk interface. > > I don't understand. You just tried to code this feature? What is the 'text > > box'? > > I did code this feature, and then killed it because it sucked :-< There is > a zoom command for the canvas which is supposed to provide "automatic" > zooming, but I couldn't make it work. Really? Is the code still in there? > By the text box, I mean the little > text thingy with the name of the widget (under the widget shape and little > people picture :). I'd probably remove icons and text boxes in the zoom view. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 11:37:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: window sill References: Message-ID: <38EB5DC2.C9F75603@geoserve.net> Brad wrote: > Will the info button be replacing the "help" window thingy that I > started using, or in addition to that? The help messages are exactly what you started but implemented differently. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Fri Apr 7 07:33:20 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:28 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: window sill Message-ID: <200004071135.HAA121862@archa12.cc.uga.edu> [...snip... my description of parent and child widgets...] Jeff wrote: > It depends on the container. I need to find one that will let me flip > between > overlapping children. The fixed-position and notebook containers come to > mind. Damn, you are so smart! This is a really good idea that I never even thought of. [...snip... description of my refresh problem...] > Did you try a Gtk refresh or a canvas refresh? I believe I tried calling both types--I think I tried request_redraw on the canvas and queue_draw on the Widget. I don't really understand how all of the refreshing works tho. >> Is this what you are proposing will replace the GtkCTree view? Will be >> have to code our own widget for this? > > No, I was suggesting to you that the 'view we have now' (the workspace normal > view) replace the GtkCTree view for taking listings of directories. The > composite GUI will look like a regular Gtk interface. Okay...how can you then distinguish between moving a locus from one workspace to another via dnd, and copying a locus unto a new workspace via dnd (ie. if you are copying a saved locus onto to the workspace to use, or if you are dragging a directory out of a representation of a local filesystem)? Will the workspace need to keep track of what kind of information it is holding? Similary, a composite representing a save directory or local filesystem will need to react different to loci that are dragged into them then a "regular" workspace would. I guess we would probably need to define two different workspace types in the code. Also, how will a workspace be populated with gui representations of loci if you, for instance, open up a save container full of loci? Just stick them with equal spacing throughout the workspace, like opening a directory on a mac? >> I did code this feature, and then killed it because it sucked :-< There is >> a zoom command for the canvas which is supposed to provide "automatic" >> zooming, but I couldn't make it work. > > Really? Is the code still in there? No, sorry, I blasted it away because, as I mentioned, it was really ugly. All I did was add a zoom in and zoom out option to the menu and attach them to workspace functions that call set_pixels_per_unit(). I can remake it really easy if you want it. But it was *really* ugly :-) Brad From bizzaro at geoserve.net Fri Apr 7 15:08:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] [Fwd: [pygtk] bonobo] Message-ID: <38EE3237.9FA6D157@geoserve.net> -------------- next part -------------- An embedded message was scrubbed... From: James Henstridge Subject: Re: [pygtk] bonobo Date: Sat, 8 Apr 2000 00:35:31 +0800 (WST) Size: 1515 Url: http://bioinformatics.org/pipermail/pipet-devel/attachments/20000407/5d754a1a/attachment.mht From bizzaro at geoserve.net Fri Apr 7 18:14:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] gtk todo Message-ID: <38EE5DE3.FCB5EDB8@geoserve.net> I thought you might find interesting some of the planned features for Gtk: http://developer.gnome.org/status/gtk+-todo.html Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 7 20:36:58 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: window sill References: <200004071135.HAA121862@archa12.cc.uga.edu> Message-ID: <38EE7F2A.A3B0694A@geoserve.net> Brad Chapman wrote: > > > No, I was suggesting to you that the 'view we have now' (the > > workspace normal view) replace the GtkCTree view for taking > > listings of directories. The composite GUI will look like a > > regular Gtk interface. > > Okay...how can you then distinguish between moving a locus from > one workspace to another via dnd, and copying a locus unto a new > workspace via dnd (ie. if you are copying a saved locus onto to the > workspace to use, or if you are dragging a directory out of a > representation of a local filesystem)? Just as you would do any DnD between objects. The workspaces are all Gtk/Gnome objects. > Will the workspace need to keep > track of what kind of information it is holding? The middleware (the 3 layers) will need to keep track of what node is where. The front will do it in a more ephemeral way (using temporary GUI objects). > Similary, a > composite representing a save directory or local filesystem will need > to react different to loci that are dragged into them then a "regular" > workspace would. Why? How will they act differently? > I guess we would probably need to define two > different workspace types in the code. Maybe, if there really is a difference between a 'storage node' and a 'working node'. I say there is no difference. And, since we're making our own distributed pseudo-filesystem, it won't be such a stretch of the imagination as it would be with a Unix filesystem: We can MAKE IT so that there is no difference. > Also, how will a workspace be populated with gui representations > of loci if you, for instance, open up a save container full of loci? > Just stick them with equal spacing throughout the workspace, like > opening a directory on a mac? Yep. I'd hide the links/connectors by default, so it would look EXACTLY like a Mac folder in 'large icon' view. Hiding links would serve another purpose I recently realized. Recall how non-connected links mean the I/O is from/to the parent node, and if you want a true dataflow 'dead-end', you'd need to cap it off somehow. I would make hidden links mean dataflow dead-ends. Going back to the workspace as a 'storage node', it would be important to hide the links of stored nodes. One may store dozens or hundreds of nodes in such a place, and we wouldn't want all of those non-connected links to end up on the parent node ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Sat Apr 8 10:36:04 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Distributed Filesystems WAS Choice of ORB implementations Message-ID: <200004081438.KAA111832@archa10.cc.uga.edu> I'm going to try to summarize some of the stuff Jarl and Jeff have been talking about and then offer my opinions. Please smack me up if I have represented anyone wrong. My quick summary: Okay, so I originally proposed a way to use the naming and trading services of corba to manage remote vsh instances and "search" for specific nodes within registered nodes. Jeff and Jarl have proposed an alternative way of doing things using a distributed filesystem approach. The choices that were mentioned for implementing this were: Jungle Monkey -> http://www.junglemonkey.net/ Gnutmeg -> http://sourceforge.net/project/?group_id=3965 My thoughts: I guess I sort of see what you guys are thinking about, but I don't really understand exactly how you are proposing to work this type of system into vsh. Let me try to think through it: 1. There is a central server (at TOL) that all instances of vsh will register with. 2. This central server will allow services for browsing and searching the registered vsh instances (like the screenshots on the Jungle Monkey page). 3. Each vsh instances will make available files that remote users can browse. Here, I don't really understand what kind of files you want to make available--xml files describing available nodes and subnets? 4. A user looking through the files finds a subnet they want to run on a remote vsh implementation. Then they need to connect to the remote vsh system (via CORBA) and request the available subnet information. How does the user get the object reference for the remote system? 5. Then things would work the same in both of the proposals. The local user would incorporate the remote node into their work flow diagram and submit the work flow diagram for processing, and then during processing all of the dl -> bl and bl -> dl and dl -> dl stuff would have to happen to do the proper processing (I won't go into that again here since that's not what we are discussing). So, do I have it semi-right? What are your guys ideas for how this will work? I also have a couple of other issues: 1. As Jarl mentioned, the distributed filesystem plan depends heavily on a central server to handle everything, and then we get into problems with load on the server and what happens if it goes down. Although I would propose that we start _initially_ with a central naming and trading service, it is possible (ie. has been done--not that I can do it yet :) to distribute these services over multiple computers. How does the distributed filesystem plan scale up? 2. How does authentication work for viewing everyones files? Does all this occur in the central server? If so, it seems like this might make the central server a big target for cracking, since if you could do so you would have access to everyone's files. For the corba services plan, the authentication would occur at each vsh instance, which might at least make things less of a target. 3. Jeff, you wrote this: > Napster has an interesting security feature, even if it was unintentional: You > don't connect directly to a remote system. You connect to the Napster server, > and the Napster server connects to the remote system. How would something > like that jive with our plans? Does this imply that every connection and filesharing and everything has to funnel through the main server? For what I want to use vsh for, this would be a serious pain. For a biological example (sorry, that's all I can think of :-), lets say I had three Suns running local BLAST servers and had 30,000 sequences to query. I'd like to be able to use vsh to "distribute" the request over the three Suns (ie. 10,000 on each) as a kind of cheap cluster or something. This is entirely a local use (and could even be occuring on one local network), but would I have to funnel all the connections through some remote central server? I don't like this, and would rather not even have to register my Suns with the remote server. The thing I like about the corba services are that they are voluntary and more of a convenience--if you could get a hold of on object instance in another way, you wouldn't even have to use them. How will the distributed filesystem plan work? Sorry to be so long--thanks if you read through all of this :-) Brad From stein at fmnh.org Mon Apr 10 08:45:43 2000 From: stein at fmnh.org (Jennifer Steinbachs) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] virtual computational and evolutionary biology laboratory (vCEBL 0.3a) 0.3a) Message-ID: This came through an evolutionary biology list. I thought it might be of some interest to loci folks. ---------- Forwarded message ---------- Date: Mon, 10 Apr 00 02:20:04 EDT From: Evoldir Reply-To: a.rodrigo@auckland.ac.nz To: stein@fmnh.org Subject: Other: vCEBL 0.3a^V virtual Computational and Evolutionary Biology Laboratory (vCEBL 0.3a) ----------------------------------------------------------------------- We are pleased to announce the release of vCEBL 0.3a. vCEBL builds a graphical user interface around a functional programming language designed specifically for evolutionary analyses. In future releases of vCEBL, users will be able to write single-line scripts that perform complex simulations or analyses using pre-existing primitive or user-supplied functions. In this alpha-release of vCEBL, we provide the basic user-interface, along with four suites of programs (or Packages) installed. Each package contains a different collection of available tools. The four packages are the Analysis, Simulation, Likelihood, and Input/Output packages. The following analyses and tools are available in vCEBL 0.3a: * Construction of serial sample phylogenies using sUPGMA or sWPGMA with sampling times known exactly or ordinally. * Construction of Neighbor-Joining, UPGMA and WPGMA phylogenies. * Estimation of pairwise distance matrices using user-specified rate matrices including general time-reversible models but not including site-to-site heterogeneity in rates. * Estimation of population parameters including substitution/mutation rates using pairwise distances with or without parametric bootstrap confidence intervals. * Maximum-likelihood branch-length optimization of user-specified unconstrained, clock-constrained or serial-sample clock-constrained trees. * ML estimation of divergence between serial samples assuming constant or varying mutation rates. * Simulation of genealogies and sequences under a constant-sized population model with or without serial sampling. Self-installing versions of vCEBL for Macintosh or Windows 95/98 can be obtained from: http://www.cebl.auckland.ac.nz/pages/vcebl.html Users will require JAVA VM 1.1.1 or higher to run vCEBL. The Applet version of vCEBL lacks the Likelihood and Input/output packages. Since vCEBL incorporates sUPGMA, the latter has been removed from our website. Details of the CEBL language can be obtained by contacting one of us through our website (http://www.cebl.auckland.ac.nz). We would greatly appreciate any feedback including bug-reports and wishlists. Allen Rodrigo Alexei Drummond Matthew Goode Computational and Evolutionary Biology Laboratory School of Biological Sciences, University of Auckland Auckland, New Zealand ******************************************************* School of Biological Sciences University of Auckland Private Bag 92019 Auckland, New Zealand Tel: 64-9-3737 599 Ext 7296 Fax: 64-9-3737 414 eFax (US): 1-413-826 5970 Email: a.rodrigo@auckland.ac.nz URL: www.cebl.auckland.ac.nz ******************************************************* ----------------------------------- J. Steinbachs, Ph.D. Computational Biologist Dept of Botany The Field Museum Chicago, IL 60605-2496 office: 312-665-7810 fax: 312-665-7158 http://cb.fmnh.org ----------------------------------- From bizzaro at geoserve.net Mon Apr 10 11:24:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] COLIMATE Message-ID: <38F1F23F.741528F3@geoserve.net> This is very similar to the approach I want to take with 'command-line construction' (Brad will recall many e-mails sent in my attempt to describe my approach): http://www.cnb.uam.es/~bioinfo/Colimate/Extra_Docs/ You can see from the screenshots that command-line options are translated into GUI widgets. The major difference between Colimate and my own plans for vsh/Loci command-line construction, is that the definition of command-line options (or the construction of the interface) is done by connecting nodes. Jeff From bizzaro at geoserve.net Mon Apr 10 18:05:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] distributed filesystem proposal Message-ID: <38F25037.FE50BD78@geoserve.net> STORAGE There are 3 places on each computer running vsh where items are kept: in (1) permanent source storage, in (2) permanent network storage, and in (3) a temporary workspaces. (1) PERMANENT SOURCE STORAGE Each vsh system keeps the source to a node in the local file system. (a) Source can be libraries, files or programs, and they are represented by a node. (b) Source Storage can manipulated by standard Unix tools. (c) Source Storage can be made publicly available or kept private. (d) Changes to Source Storage must be reflected in the Network Storage (see below). (2) PERMANENT NETWORK STORAGE Each vsh system has its own virtual filesystem for storing nodes and networks. (a) Networks are NOT stored according to any conventional filesystem rules. (b) Networks are stored as XML representations with linkage information and information about the location of the Source. (c) Multiple volumes (more in part 3) of the Network Storage can be made and designated public or private. (d) Public volumes can be mounted by anyone across a network. But changes cannot be made. (e) Private volumes can be mounted only by those with permission. (f) A 'lock' is required on a volume for anyone who is able to change it. (g) Using a Network Storage volume requires that a connection has been established with the Storage. So, any changes made can be reflected in the Storage. (h) Volumes can be copied from one system to another. (3) VOLUMES AND TEMPORARY WORKSPACES Almost all of the functionality of a Workspace is akin to a word processor working on a document. (a) When a user mounts a Network Storage volume s/he 'opens' it, and a temporary copy of the volume is placed in a Workspace. (And the volume is locked.) (b) When a user chooses to 'save' any node or network within the volume, the changes are reflected in the volume. (c) The user can also choose to 'close' or 'unmount' a volume and make a 'new' one. (d) Workspaces are not just volumes. They are used for all networks and subnets. (d) Workspaces are not isolated. They are in fact nodes that can be placed in parent Workspaces. (Some changes in a Workspace MAY cause changes in a parent Workspace, and that needs to be considered.) (e) From the description above, Workspaces seem to be like files. But their ability to store other Workspaces makes them more like directories. PEERS About the use of a central server and peer-2-peer connections: Since every vsh system will have this filesystem, it makes no difference what computer the user connects to. So, peer-2-peer is native. On the other hand, we can set up one or more cummunity servers where volumes of Network Storages can be publicly mounted. This will make many nodes available to the new vsh user. THE PROCESS (running vsh) Vsh will work the following way, from selecting a peer to running a network (Gnome GUI specifics are included): (1) The URI of a peer is entered, and a connection is made. (2) The user can see a list of volumes available on the remote computer, which are public or private, and which are already mounted and locked by other users. (3) The user chooses to mount a private volume. This is the same as 'opening' a volume. A Workspace is made with a copy of what is in the volume. The volume is locked by the user, so no one else can use it. (4) The user makes changes to networks and nodes within the Workspace. No changes are made to the volume yet. (5) The user chooses to 'save' a node, network, or Workspace containing them (anything that can be saved). This changes the volume on the remote computer. (6) The user chooses to 'run' a network in the volume. Vsh then parses the network information kept locally. And when the source of a node needs to be contacted or downloaded, a connection is made to the Source Storage on whatever computer has the source. (7) The user chooses to 'close' or 'unmount' a volume. If changes have been made since the last save, vsh prompts the user about saving before closing. The volume is unmounted and unlocked. The Workspace disappears. Comments please. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 20:11:10 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: distributed filesystem proposal References: <38F25037.FE50BD78@geoserve.net> Message-ID: <38F26D9E.8459068B@geoserve.net> "J.W. Bizzaro" wrote: > > (3) VOLUMES AND TEMPORARY WORKSPACES Volumes are defined as completely isolated networks. IOW, they have no inputs or outputs. They are the highest level of networks. They could be simply called 'networks' if all the networks they contain are called 'subnets'. I think this is how Overflow defines these. Also, a volume (or 'network') is an XML description of connections between subnets and nodes, as we have been saying all along. And this description resides on ONE COMPUTER (or in one BL). Brad and I were just talking about this over chat. We think a connection made to find out what volumes are available will be done via DL -> Internet -> DL -> BL connection. Mounting, opening and locking volumes are handled the same way. What differs from this mechanism is how network execution is handled. Of course, the source to a node (a program for example) can be at yet another location. In such a case, the server that stores the volume needs to make a connection to the other server. But I'm wondering if it is the remote server or the local server that should be doing the execution of the network in the volume. BOTH have copies of the network, correct? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 20:44:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] overall Message-ID: <38F2757D.7B28F6F6@geoserve.net> Overall, we'll have... 3 types of storage (1) Source (2) Network (3) Workspace 3 types authentication (1) Access to source (2) Access to network (3) Access to workspace (handled by UI) 2 types of connections/requests (1) Opening of network (mounting of volume) (2) Execution of source Correct? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 20:56:00 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: overall References: <38F2757D.7B28F6F6@geoserve.net> Message-ID: <38F27820.A6A81A35@geoserve.net> Maybe make it all 3's: 3 types of storage (1) Source (2) Network (3) Workspace (handled by UI/DL) 3 types authentication (1) Access to source (2) Access to network (3) Access to workspace (handled by UI/DL) 3 types of connections/requests (1) Execution of source (2) Opening of network (mounting of volume) (3) Joining a session (handled by UI/DL) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 11 12:52:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] thoughts on UI->DL communication Message-ID: <38F3584C.4084EB51@geoserve.net> Brad, Jarl and I were all talking about UI->DL communication over chat. I want to summarize my own thoughts. First, the VSH plan for the UI->DL parts and the communication between them, is to re-use Loci's Front->Middle parts and communication. So, VSH Loci ------ ------ UI->DL == Front->Middle But Loci's Front->Middle parts and communication are also very similar in design to VSH's DL->BL parts and communication. Both Front->Middle and DL->BL... * Act like client->server * Pass XML * Need authentication to connect * Can connect across a network So, I see a lot of duplication between UI->DL and DL->BL in the current plan that need not be there. Jarl suggested that VSH use 1 UI per DL. This makes DL a client rather than a server and eliminates much of the duplication mentioned above. But I wonder, if there is only 1 UI per DL, why do they need to be separate? Could they both be in Python? I think there are several advantages: (1) Speed: Direct Python communication rather than socket (2) Less processes running: 1 processes rather than 2 (3) Unified code base (4) One less authentication system needed (recall we would need 3) (5) Elimination of sockets: keep corba as the only protocol (6) No XML management (reading and writing) between the two I would propose that both the UI and the DL be combined into one Python code base, and have the UI (in particular, the Gnome UI) be a module library for the DL to import. This UI library would have a well defined API with events, etc. But Brad pointed out that there would be (at least) 2 problems: (1) There would be a lot of rewriting to do, which would make Brad very unhappy. I'm not suggesting that we re-integrate the two parts. I think the separation is good, because the use of the UI as a library would require a separate anyway. And as far as work goes, I can do it myself. (2) Other UI's would have to be made in Python. Actually, there are 2 ways we can make UI's in other languages: (a) The whole UI->DL part can be written in another language and use CORBA to communicate with the BL. (b) Write a UI part in Python that can communicate with non-Python UI's, using a language-neutral protocol like CORBA. My argument for doing it now is this: IT WILL BE A LOT HARDER LATER ON WHEN THE UI->DL PROTOCOL BECOMES BETTER DEVELOPED! Comments? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 11 13:28:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> Message-ID: <38F360B8.8BCE49B4@geoserve.net> I also think the BL needs to handle the management of permanent network/volume storage. The DL/UI will handle the temporary loading of networks/volumes into a workspace. Coordinated control of a network/volume by multiple UI's/DL's will be handled the following way: UI UI | | \|/ \|/ DL _____\ DL / | \|/ root DL | \|/ BL As per Jarl's suggestion. So, there really is only DL->DL authentication, correct? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:42 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21091@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] Re: which handles distribution (was: vsh?) > --- Bodytext delivered in separate SMS messages --- (1/2) Hi Jean, There's a lot o'discussion going on in the vsh mailinglist, and you're not commenting on them so I'm asking if you could give us your opinion is (2/2) on a few postings. thnx, jarl __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:32 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21293@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: brad chapman : [Pipet Devel] Moving forward in the middle > --- Bodytext delivered in separate SMS messages --- (1/10) Hey Jeff (and anyone else who is interested); I just wanted to let you know my coding plans for this upcoming weekend because I'd like to try and coordi (2/10) nate front development along with what I'm doing so we can get it implemented and test it out. As I mentioned, I've pulled myself out of the GUI comlete (3/10) ly so that I won't be interfering there any more :-) As a result this has led me to start thinking about how to implement stuff xml-wise and not gui-wis (4/10) e, so I could use your input. Specifically what I'm blathering about is that I've just about (keeping my fingers crossed here!) got a generalized loci d (5/10) isconnection communication protocol finished (and partly implemented in the GUI, but only during deletion of loci, and I have not thought about providin (6/10) g a way for generalized disconnecting of loci). This weekend I'm hoping to tackle persistance/saving of loci in the back/private directory and, if I am (7/10) really lucky, start thinking about how to try to whip up a connection diagram into a good XML representation (of course, we have to work the basis of th (8/10) is out with the other vsh guys). Do you have ideas about how these things should work in the GUI? I'll need the GUI to test things out and make sure I'm (9/10) implementing them properly, and just thought we could try and coordinate stuff and get this all working beautifully as soon as we can. What do you thin (10/10) k? What are your plans? Brad __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From chapmanb at arches.uga.edu Tue Apr 25 08:01:00 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: [Pipet Devel] summary for web page and announcements Message-ID: <200004251203.IAA117196@archa10.cc.uga.edu> Jeff wrote: > And after we get that put up, I would like to make some announcements about > the collaboration. I know that we don't have a working system yet, but I can > mention that Overflow, GMS and Loci have merged. And I can mention what our > plans are. This is very important so that people know we are here, and so > that no-one tries to make a VSh of their own ;-) Well, before we start announcing we should probably actually decide on a final name for the program... I was thinking about this a bit in my genetics class and came up with an idea for a name: Hedgehog Why? What the heck are you talking about, Brad? Well, the hedgehog family of proteins are a really important set of molecules for controlling development in flies and mammalian systems. They are signal transduction proteins that pass developmental information from cell to cell and are responsible for proper formation of patterning in developing embryos (so they help detemine what if your back and front and right and left sides). So I thought this was analagous to vsh/loci/gms/overflow in the following way: Biology Our program -------- ---------- cell-cell communication => program-to-program communication proper embryo development => proper workflow development So Hedgehog is a protein that coordinates cells to develop in a good way, and vsh is a program that coordinates programs and libraries to flow together in a good way. Whadda you all think? The added advantages are that it has a easy acronym (hh) and that we can put pictures of hedgehogs on our site without people taking us away to the mental hospital :-) Brad From jean-marc.valin at hermes.usherb.ca Tue Apr 25 08:42:41 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: [Pipet Devel] summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> Message-ID: <390592C1.1AB00200@hermes.usherb.ca> > So Hedgehog is a protein that coordinates cells to develop in a good > way, and vsh is a program that coordinates programs and libraries to > flow together in a good way. > > Whadda you all think? The added advantages are that it has a easy > acronym (hh) and that we can put pictures of hedgehogs on our site > without people taking us away to the mental hospital :-) I would prefer a name that has a meaning to everybody. Also, it has to reflect the fact that you can use the software for many applications, from biology to speech and image processing. I think it would be nice to have the word "flow" in the name (that's why I chose "Overflow") if possible (but I won't complain too much if we don't). Jean-Marc From gvd at redpoll.pharmacy.ualberta.ca Tue Apr 25 09:14:45 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: [Pipet Devel] summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> Message-ID: <39059A45.D67A9136@redpoll.pharmacy.ualberta.ca> Brad Chapman wrote: > > Jeff wrote: > > And after we get that put up, I would like to make some > announcements about > > the collaboration. I know that we don't have a working system yet, > but I can > > mention that Overflow, GMS and Loci have merged. And I can mention > what our > > plans are. This is very important so that people know we are here, > and so > > that no-one tries to make a VSh of their own ;-) > > Well, before we start announcing we should probably actually > decide on a final name for the program... > I was thinking about this a bit in my genetics class and came up > with an idea for a name: > > Hedgehog > Hehe, yeah, their are a lot of derivatives of this name, includin the 'sonic the hedgehog' gene! I know jeff like Vsh, and I'm okay with it, but If i were to proffer a name, I think: DataFlower would be kind of cute. Abstracted out (the way it is know) our application is really a data connectivity brokering application, taking data from one resource and passing it through others in a network-distributed environment. The data 'flows' from one 'resource' to another under the control of a data flow gui, and really, DataFlower encapsulates that idea well, and is precocious enough to attract some noteriety imo. it may sound 'pansy', but geez, just look at all the daisys in the gnome distribution! regards, g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From bizzaro at geoserve.net Tue Apr 25 09:59:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] name game (was: summary for web page and announcements) References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> Message-ID: <3905A4BC.DCB75218@geoserve.net> Brad wrote: > > So Hedgehog is a protein that coordinates cells to develop in a good > way, and vsh is a program that coordinates programs and libraries to > flow together in a good way. > > Whadda you all think? The added advantages are that it has a easy > acronym (hh) and that we can put pictures of hedgehogs on our site > without people taking us away to the mental hospital :-) Jean-Marc Valin wrote: > > I would prefer a name that has a meaning to everybody. Also, it has to reflect > the fact that you can use the software for many applications, from biology to > speech and image processing. I think it would be nice to have the word "flow" in > the name (that's why I chose "Overflow") if possible (but I won't complain too > much if we don't). I think Hedgehog is cute. But being so, it is probably taken :-/ I guess I agree with Jean-Marc that the name should give the prospective user some indication as to what the program does. I get the Hedgehog analogy, but non-biologists would not. I was growing fond of VSh, particularly 'GNU Visual Shell'. I like it for the following reasons: * To say that the program is 'THE' visual shell for GNU is pretentious and presumptuous, and it will garner the attention the program deserves. * 'Visual Shell' and even VSh say exactly what we're the program is: a visual shell! The term is commonly used to describe graphical environments like Gnome, but I could find only one program that used it (in 1984) as a name. You know, but Gnome, KDE, and the stuff Eazel is working on...THAT'S ALL WIN/MAC CRAP! Let's show everyone how a true UNIX *shell* should work! * I *REALLY* want to have the word 'GNU' in the name. That alone will attract attention and tell people that this is free-as-in-speech software. A couple people pointed out to me that we could abbreviate 'GNU Visual Shell' as 'vshgnu' (like the Hindu god Vishnu). It'd be cute, if it isn't offensive to any Hindus ;-) And 'gnu' pronounced as 'new' can indicate that this is the 'New VSh' (the old VSh being from 1984). Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:07:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:29 2006 Subject: [Pipet Devel] Re: summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> <39059A45.D67A9136@redpoll.pharmacy.ualberta.ca> Message-ID: <3905A6B1.7E4013EA@geoserve.net> Gary Van Domselaar wrote: > > I know jeff like Vsh, and I'm okay with it I also like 'Loci' :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:11:41 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> Message-ID: <3905A79D.E586874F@geoserve.net> Jean-Marc Valin wrote: > > I would prefer a name that has a meaning to everybody. Also, it has to reflect > the fact that you can use the software for many applications, from biology to > speech and image processing. I think it would be nice to have the word "flow" in > the name (that's why I chose "Overflow") if possible (but I won't complain too > much if we don't). Please don't take this the wrong way, but the name 'Overflow' makes me think 'stack overflow error'. And you probably don't want to associate your program with a common error ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:15:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: name game (was: summary for web page and announcements) References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A4BC.DCB75218@geoserve.net> Message-ID: <3905A88B.DFB1FCD1@geoserve.net> "J.W. Bizzaro" wrote: > > A couple people pointed out to me that we could abbreviate 'GNU Visual Shell' > as 'vshgnu' (like the Hindu god Vishnu). And when we go to conferences, we can shave our heads, don pink robes, and sing, 'Hari Hari, Vshgnu Vshgnu, Hari Rama, Vshgnu Vshgnu' :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:51:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Mesquite References: <390442F2.A47B862E@geoserve.net> <39049874.88FD9FD4@redpoll.pharmacy.ualberta.ca> Message-ID: <3905B107.8997B7BA@geoserve.net> Jennifer wrote: > > I've started playing with a new program targeted to evolutionary > biologists, called Mesquite. Wayne Maddison is one of the authors > (UArizona I think). On first glance, the principals looked similar to > LOCI, so I suggested he contact you. On a second glance, it really > parallels LOCI, with the major exception being that Mesquite is written in > java. I don't recall his web page offhand, but if you do a search on > Maddison and Mesquite, you should find his page with little trouble. [...] > After playing a bit more, Mesquite is clearly designed for post-alignment > anaysis of sequences :( Given the file format the authors are using, it > would be difficult to change that. Gary wrote: > > You can find the web page at: > > http://spiders.arizona.edu/mesquite/mesquite.html > > From my first pass at the documentation, mesquite appears to be an > evolulationary analysis development environment. It provides modules > and libraries for phylogenetic manipulation. It has a modular design, so > developers can glue generic utilities (charts, data editors, tree > manipulators, etc.), and add their own specific functionality, into a > specialized application for evolutionary analysis. It has elements that > are similar to Loci/Vsh, but is not quite as abstracted, IMO. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Tue Apr 25 11:06:53 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A79D.E586874F@geoserve.net> Message-ID: <3905B48D.7FE0011B@hermes.usherb.ca> > > I would prefer a name that has a meaning to everybody. Also, it has to reflect > > the fact that you can use the software for many applications, from biology to > > speech and image processing. I think it would be nice to have the word "flow" in > > the name (that's why I chose "Overflow") if possible (but I won't complain too > > much if we don't). > > Please don't take this the wrong way, but the name 'Overflow' makes me think > 'stack overflow error'. And you probably don't want to associate your program > with a common error ;-) Just to make it clear, I wasn't suggesting using Overflow, since it would make things confusing. I just though having the word "flow" in the name would tell a bit about what the software's doing. As for the 'stack overflow error' meaning, that was actually intended when we chose the name, so I don't feel offended. Jean-Marc From rree at oeb.harvard.edu Tue Apr 25 11:41:45 2000 From: rree at oeb.harvard.edu (Rick Ree) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Mesquite In-Reply-To: <3905B107.8997B7BA@geoserve.net> Message-ID: I've also tried Mesquite. IMHO Java is just not all it's cracked up to be for GUI's, at least on Linux: it just feels sluggish, klunky widgets, and so on (I think Mesquite uses AWT and not Swing, though). Has anyone ever come across a non-trivial Java app where the GUI feels right? I'd be interested to know. Also, while the Maddisons have expressed some interest in open source (I've asked them about it a couple of times), from what I can tell the Mesquite environment is pretty closed and restricted, and wedded to Java (no CORBA, etc). IMHO it's too bad the core libraries are in Java and not C (meaning no nice PyGTK interface ;) In summary, I think Mesquite was a good idea, but it's not something I see myself using in the future -- unlike Loci, which has the potential to be an excellent phylogenetic analysis backbone. Rick On Tue, 25 Apr 2000, J.W. Bizzaro wrote: > Jennifer wrote: > > > > I've started playing with a new program targeted to evolutionary > > biologists, called Mesquite. Wayne Maddison is one of the authors > > (UArizona I think). On first glance, the principals looked similar to > > LOCI, so I suggested he contact you. On a second glance, it really > > parallels LOCI, with the major exception being that Mesquite is written in > > java. I don't recall his web page offhand, but if you do a search on > > Maddison and Mesquite, you should find his page with little trouble. > [...] > > After playing a bit more, Mesquite is clearly designed for post-alignment > > anaysis of sequences :( Given the file format the authors are using, it > > would be difficult to change that. > > Gary wrote: > > > > You can find the web page at: > > > > http://spiders.arizona.edu/mesquite/mesquite.html > > > > From my first pass at the documentation, mesquite appears to be an > > evolulationary analysis development environment. It provides modules > > and libraries for phylogenetic manipulation. It has a modular design, so > > developers can glue generic utilities (charts, data editors, tree > > manipulators, etc.), and add their own specific functionality, into a > > specialized application for evolutionary analysis. It has elements that > > are similar to Loci/Vsh, but is not quite as abstracted, IMO. > > Jeff > -- > +----------------------------------+ > | J.W. Bizzaro | > | | > | http://bioinformatics.org/~jeff/ | > | | > | BIOINFORMATICS.ORG | > | The Open Lab | > | | > | http://bioinformatics.org/ | > +----------------------------------+ > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel > From gvd at redpoll.pharmacy.ualberta.ca Tue Apr 25 17:40:33 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] name game Message-ID: <390610D1.984295@redpoll.pharmacy.ualberta.ca> so noone liked DataFlower? I'm crushed :-( -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From stein at fmnh.org Tue Apr 25 17:42:52 2000 From: stein at fmnh.org (Jennifer Steinbachs) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] name game In-Reply-To: <390610D1.984295@redpoll.pharmacy.ualberta.ca> References: <390610D1.984295@redpoll.pharmacy.ualberta.ca> Message-ID: <200004252142.QAA22225@mail.fmnh.org> I did, but, then again, I'm partial to plants :) Quoting Gary Van Domselaar : > so noone liked DataFlower? I'm crushed :-( ------------------------ J. Steinbachs, PhD Computational Biologist Dept Botany The Field Museum Chicago, IL 60605-2496 312-665-7810 312-665-7158 (fax) http://cb.fmnh.org ------------------------- From bizzaro at geoserve.net Tue Apr 25 23:35:55 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: name game References: <390610D1.984295@redpoll.pharmacy.ualberta.ca> Message-ID: <3906641B.EB8CE7FE@geoserve.net> Gary Van Domselaar wrote: > > so noone liked DataFlower? I'm crushed :-( Crushed like a little flower, dataflower that is ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 23:51:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: collaboration naming References: Message-ID: <390667D7.62E9CFD@geoserve.net> deanne@density.biop.umich.edu wrote: > > Close to "Trias", too TRIO: T(something) R(something) Input with Overflow? They're nice suggestions, really. I am partial to Latin and Greek words, as evidenced by my choice of "Loci" for one of the "triad" projects. But, I wouldn't want to emphasize that there are distinct and separate parts to this project, or that 3 programs were glued together (there are actually 4 layers to the project, BTW). People should see this as a single program and not have to be reminded of the collaboration behind it (So, "Unum" and "Unisys" are out too ;-)). This could have been a collaboration of 2, 3, 4, 5, 6, etc. projects, and what difference would it make to the user? It says nothing about what the program DOES...and it doesn't give us a cute mascot either ;-) > (I'm trying to FIND a job in bioinformatics at this point...talk about > difficult...still here, just caught up in other foo). Bioinformatics.org will soon have a section for posting job opportunities in the field. You may want to stay tuned for that. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 01:13:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] name References: <39067965.EF11748A@geoserve.net> Message-ID: <39067B0B.49317A54@geoserve.net> > BTW, how about the name "pipeline"? pipeline piper pipes gnupipes ("new pipes") Maybe even... plumber visual pipes tubes pvc copper They convey the idea of "flow", don't they? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 02:15:48 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Genpak Message-ID: <39068994.2D02AA95@geoserve.net> http://www.rzuser.uni-heidelberg.de/~jweiner1/Genpak/ Jeff From bizzaro at geoserve.net Wed Apr 26 02:45:50 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Punnetizer Message-ID: <3906909E.40CFEE89@geoserve.net> (I'm just having fun going through some biology apps I found at Freshmeat.) The Punnetizer - creates Punnet squares (biology/genetics) and analyze the outcomes. Outputs in plain text, tab-separated ASCII, HTML, and LaTeX. I wrote this to get out of manually making a huge one in biology class. http://quadium.net/code/punnet.c Jeff From bizzaro at geoserve.net Wed Apr 26 02:50:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Ghemical Message-ID: <390691AE.49526C29@geoserve.net> Ghemical is a computational chemistry software package released under the GNU GPL. It means that full source code of the package is available, and users are free to study and modify the package. Ghemical is being developed in the University of Kuopio, Finland, in the Department of Chemistry. http://www.uku.fi/~thassine/ghemical/ Jeff From bizzaro at geoserve.net Wed Apr 26 02:42:16 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] LEKSBOT Message-ID: <39068FC8.4CD2E9EA@geoserve.net> LEKSBOT is an explanatory dictionary of botanic and biological terms. Curently it contains about 1500 terms but the number is growing up and will cover other sciences relative with biology (entomology, etc.). http://agriroot.aua.gr/nickapos/Eng/DownloadEnglish.htm Jeff From bizzaro at geoserve.net Wed Apr 26 02:52:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Garlic Message-ID: <39069232.A196216E@geoserve.net> Garlic is a free molecular visualization program that loads and displays PDB (Protein Data Bank) files. It can display proteins, DNA molecules, and other molecules. Unlike RASMOL, garlic can load and display more than one macromolecular structure. Molecules may be rotated and translated. Color is used to create a pseudo-3D effect, and slab may be applied to hide parts of the structure. Garlic requires no special hardware (like dials); the numeric keypad is used for rotations and translations. http://pref.etfos.hr/garlic/ Jeff From bizzaro at geoserve.net Wed Apr 26 02:59:32 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Garlic References: <39069232.A196216E@geoserve.net> Message-ID: <390693D4.4330557A@geoserve.net> "J.W. Bizzaro" wrote: > > Garlic is a free molecular visualization program that loads and displays PDB > (Protein Data Bank) files. It can display proteins, DNA molecules, and other > molecules. Unlike RASMOL, garlic can load and display more than one > macromolecular structure. Molecules may be rotated and translated. Color is > used to create a pseudo-3D effect, and slab may be applied to hide parts of > the structure. Garlic requires no special hardware (like dials); the numeric > keypad is used for rotations and translations. > > http://pref.etfos.hr/garlic/ Dang that's purdy! Check out the screenshots page: http://pref.etfos.hr/garlic/gallery/index.html Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 03:06:10 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] DINO: Visualizing Structural Biology Message-ID: <39069562.10C2928F@geoserve.net> (I guess there are plenty of molecular modeling apps out there ;-)) DINO is a realtime visualization program for structural biology data, including protein and nucleic-acid coordinates, molecular surfaces, electrostatic potentials, electron densities, surface topographs (from AFM), and MD trajectories. It supports PNG, TIFF, PostScript, and POVray output. http://www.bioz.unibas.ch/~xray/dino/ Jeff From bizzaro at geoserve.net Wed Apr 26 03:09:55 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] DINO: Visualizing Structural Biology References: <39069562.10C2928F@geoserve.net> Message-ID: <39069643.BE19F531@geoserve.net> "J.W. Bizzaro" wrote: > > (I guess there are plenty of molecular modeling apps out there ;-)) > > DINO is a realtime visualization program for structural biology data, > including protein and nucleic-acid coordinates, molecular surfaces, > electrostatic potentials, electron densities, surface topographs (from AFM), > and MD trajectories. It supports PNG, TIFF, PostScript, and POVray output. > > http://www.bioz.unibas.ch/~xray/dino/ If you look at the screenshot galleries, you'll see that this is one VERY IMPRESSIVE renderer. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 02:40:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] ppovit Message-ID: <39068F73.CA5D5E0E@geoserve.net> Ppovit is a small perl program that reads 3-D molecular structure coordinates in Protein Data Bank (PDB) format and generates a scene description script that can be used as input for the Persistence Of Vision (POV) ray-tracer to create high quality images of macromolecular models. http://huron.cem.msu.edu/~rstc/ppovit/ Jeff From bizzaro at geoserve.net Wed Apr 26 03:33:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: name References: <39067965.EF11748A@geoserve.net> <39067B0B.49317A54@geoserve.net> Message-ID: <39069BC1.7C90214E@geoserve.net> "J.W. Bizzaro" wrote: > > pipeline > piper > pipes > gnupipes ("new pipes") > plumber > visual pipes > tubes > pvc > copper and... pipeworks Alright, I stop the e-mail barrage Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 03:53:30 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: name References: <39067965.EF11748A@geoserve.net> <39067B0B.49317A54@geoserve.net> <39069BC1.7C90214E@geoserve.net> Message-ID: <3906A07A.9D7E99FA@geoserve.net> "J.W. Bizzaro" wrote: > > piper I like piper. Then I can call my gnome UI "pied" ("patchy colors" as in "The Pied Piper"). And we can have The Pied Piper as a mascot :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From thomas at cbs.dtu.dk Wed Apr 26 13:38:37 2000 From: thomas at cbs.dtu.dk (thomas@cbs.dtu.dk) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: [pyphy] Thomas Sicheritz In-Reply-To: <390511C4.C4C96C1A@geoserve.net> References: <390511C4.C4C96C1A@geoserve.net> Message-ID: <14599.10653.428037.656600@genome.cbs.dtu.dk> J.W. Bizzaro writes: > Does anyone know where Thomas Sicheritz has gone? His email address and web > site at bmc.uu.se don't work anymore. Yes, I do :-) I just started my postdoc at the Center for Biological Sequence Analysis in denmark. I have not yet had time to move and update all my webpages. Tomorrow I am going to Bioinformatics2000 (http://www.cbs.dtu.dk/bioinformatics2000/) - am I going to meet other loci'er there ? -thomas -- Sicheritz Ponten Thomas E. CBS, Department of Biotechnology blippblopp@linux.nu The Technical University of Denmark CBS: +45 45 252485 Building 208, DK-2800 Lyngby Fax +45 45 931585 http://www.cbs.dtu.dk/thomas/index.html Molecular Python: http://evolution.bmc.uu.se/~thomas/python Molecular Linux: http://evolution.bmc.uu.se/~thomas/mol_linux De Chelonian Mobile ... The Turtle Moves ... From bizzaro at geoserve.net Wed Apr 26 23:40:03 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] piper Message-ID: <3907B693.A8C12939@geoserve.net> Does anyone like the name "piper"? Look at the sandpiper pic attached. Aint it cute? :-) Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: sandpiper.jpg Type: image/jpeg Size: 31743 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000427/7937f5c0/sandpiper.jpg From deanne at density.biop.umich.edu Wed Apr 26 23:40:47 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: [Pipet Devel] piper In-Reply-To: <3907B693.A8C12939@geoserve.net> Message-ID: I like "piper"... |-er |er Heh. Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor On Thu, 27 Apr 2000, J.W. Bizzaro wrote: > Does anyone like the name "piper"? > > Look at the sandpiper pic attached. Aint it cute? :-) > > Jeff From jean-marc.valin at hermes.usherb.ca Wed Apr 26 23:53:44 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: [Pipet Devel] piper References: Message-ID: <3907B9C8.3E0591E8@hermes.usherb.ca> deanne@density.biop.umich.edu a ?crit : > > I like "piper"... I also think it's a good name. Another think to think about though is that we need to find a project name, but we'll need to find names for the different apps in the project. For example in the Overflow project, there are the "VFlow" and "batchflow" apps. It would be nice to have related names for apps. Any idea of a "theme" around "piper"? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From deanne at density.biop.umich.edu Thu Apr 27 00:35:04 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:30 2006 Subject: [Pipet Devel] Re: [Pipet Devel] piper In-Reply-To: <3907B9C8.3E0591E8@hermes.usherb.ca> Message-ID: > > I also think it's a good name. Another think to think about though is that we > need to find a project name, but we'll need to find names for the different apps > in the project. For example in the Overflow project, there are the "VFlow" and > "batchflow" apps. It would be nice to have related names for apps. Any idea of a > "theme" around "piper"? > [Nouns] musician, artiste, performer, player, minstrel; bard (poet) [more]; accompanist, accordionist, instrumentalist, organist, pianist, violinist, flautist; harper, fiddler, fifer, trumpeter, piper, drummer; catgut scraper. http://scottishculture.about.com/culture/scottishculture/library/blhumpipes.htm?rnk=r7&terms=piper ...and I want to author an application called 'haggis'. :) How about fifer, fiddler? Bard? (above is from www.thesaurus.com) From bizzaro at geoserve.net Thu Apr 27 00:55:13 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Re: piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> Message-ID: <3907C831.777F747@geoserve.net> Jean-Marc Valin wrote: > > I also think it's a good name. Another think to think about though is that we > need to find a project name, but we'll need to find names for the different apps > in the project. For example in the Overflow project, there are the "VFlow" and > "batchflow" apps. It would be nice to have related names for apps. Any idea of a > "theme" around "piper"? There are lots of words associated with "piper" and "pipe" that would give us a theme: pied (as in "pied piper" fairy tale) (anything to do with the fairy tale - e.g., "rats", "Hamelin", "legend") drummer (as in "piper and drummer") (anything to do with pipe or flute playing - e.g., "bag piper", "pipe organ", "tabor") sand (as in "sandpiper"; also species "peep", "knot", "sanderling") (anything to do with sandpipers or birds - e.g., "shore", "footprint", "winged") (anything to do with Piper airplanes - e.g., "Cub", "Saratoga") peter (as in "Peter Piper picked a pack of pickled peppers") pepper (plant of the "piperaceae" taxonomic order; also "piperine") (anything to do with water pipes and plumbing - e.g., "pipeline", "steam pipe") pay (as in "pay the piper") dream (as in "pipe dream") bomb (as in "pipe bomb") (anything to do with tobacco pipes - e.g., "peace pipe") Whew! Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Apr 27 08:04:35 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Re: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> Message-ID: <39082CD3.1931C8F4@geoserve.net> jarl van katwijk wrote: > > I'm ok with Piper to. The vote is... Jeff: YES Jean-Marc: YES Jarl: YES (Deanne: YES) Still missing: Brad: Flower^H^H^H^H^H^HGary: Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Thu Apr 27 08:25:19 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc In-Reply-To: <3907B693.A8C12939@geoserve.net> Message-ID: I thought I'd take a side tack for a moment and tell you guys what I'm doing and why it's taking me so long to get up to speed. Python is eeaaaasy. I have the O'reilly book and so far i love the language. It makes perfect sense. Gnome took forever to correctly configure on my machine and I'm still getting odd errors that I can't trace, now and again. I still can't get my soundcard to work. :) I had to re-build the whole system on my box and compile a new kernel and new glib and etc....needed to be done, but took me a bit of time. Oh, yea, and in all of this, I'm trying to write a journal article on quantum physics/NMR and finish my thesis. I've also been looking for jobs in bioinformatics (which is how I found you guys, btw, which was a nice coincidence). I have an interview at Harvard Medical School as a research computing scientist in bioinformatics, a job offer that's kind of weird at Novartis Functional Genomics Institute (check out www.nifg.org, they've got openings in their computational biology area) and also possibly other job opportunities at a few other pharm companies, though we'll see. A few comments, unsolicited, from a job hunter: 1) Rosetta Inpharm has lousy interviewers with bad attitude 2) Novartis IFG offered me a job and then is kind of backpedaling a bit, somehow wondering if I can "handle" more of a concentration in biology (!) 3) Harvard Med School is very cool with neat people. So far. 4) It's hard to convince anyone in bioinformatics industry/academia that if you haven't been a bioinformatics graduate student but have had all the relevant experience, that you can "do this". Which is kind of silly. Anyway, I'll be away until Monday. Wish me luck and productivity. Your new-found friend, Deanne From bizzaro at geoserve.net Thu Apr 27 08:41:48 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: Message-ID: <3908358C.D270697B@geoserve.net> deanne@density.biop.umich.edu wrote: > > I've also been looking for jobs in bioinformatics (which is how I found > you guys, btw, which was a nice coincidence). I have an interview at > Harvard Medical School as a research computing scientist in > bioinformatics Definitely come (I live there) to Boston! It's becoming Bioinformatics Central, as evidenced by Gary's arrival next year ;-) > 4) It's hard to convince anyone in bioinformatics industry/academia that > if you haven't been a bioinformatics graduate student but have had all the > relevant experience, that you can "do this". Which is kind of silly. Tell me about it. As if there are sooooo many Ph.D. programs in bioinformatics out there! Personally, I think computer skills are more important than having a pure (non biochem or biophysics) background. You usually focus on a single biological problem in bioinformatics, so there can be less biology to learn than computing/programming. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Apr 27 08:49:46 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: <3908358C.D270697B@geoserve.net> Message-ID: <3908376A.D0FB355D@geoserve.net> "J.W. Bizzaro" wrote: > > Tell me about it. As if there are sooooo many Ph.D. programs in > bioinformatics out there! Personally, I think computer skills are more > important than having a pure (non biochem or biophysics) background. You > usually focus on a single biological problem in bioinformatics, so there can > be less biology to learn than computing/programming. "Pure" biologists are such snobs when it comes to the allied fields. I can attest to that in my many failed attempts to cross over from chemistry. But don't get me going on that...I want to keep people ON this list :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Thu Apr 27 08:45:06 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc In-Reply-To: <3908358C.D270697B@geoserve.net> Message-ID: > deanne@density.biop.umich.edu wrote: > > > > I've also been looking for jobs in bioinformatics (which is how I found > > you guys, btw, which was a nice coincidence). I have an interview at > > Harvard Medical School as a research computing scientist in > > bioinformatics > > Definitely come (I live there) to Boston! It's becoming Bioinformatics > Central, as evidenced by Gary's arrival next year ;-) Excellent. Boston is my home town.I'm only out here in Ann Arbor for the degree and then I want to come back home. I lived up in Saugus for too many years. :) > Tell me about it. As if there are sooooo many Ph.D. programs in > bioinformatics out there! Personally, I think computer skills are more > important than having a pure (non biochem or biophysics) background. You > usually focus on a single biological problem in bioinformatics, so there can > be less biology to learn than computing/programming. Right! The only time you'd have to worry about it is if you were directing projects or something. Or supporting many research labs (like the harvard job is asking for). I'll be staying in downtown boston all weekend; my flight leaves at 3pm. if anyone in boston feels social, give me an email; if not, talk to you guys later. I'm leaving now. Really. D From jarl at casema.net Thu Apr 27 07:46:36 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: <3908358C.D270697B@geoserve.net> Message-ID: <3908289C.8A091073@casema.net> > > Tell me about it. As if there are sooooo many Ph.D. programs in > bioinformatics out there! Personally, I think computer skills are more > important than having a pure (non biochem or biophysics) background. You > usually focus on a single biological problem in bioinformatics, so there can > be less biology to learn than computing/programming. Maybe somebody can give me some URL to a site that's explaining what the definition of 'bioinformatics' is? From bizzaro at geoserve.net Thu Apr 27 09:02:42 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: Message-ID: <39083A72.D4023662@geoserve.net> deanne@density.biop.umich.edu wrote: > > Excellent. Boston is my home town.I'm only out here in Ann Arbor for the > degree and then I want to come back home. I lived up in Saugus for too > many years. :) More specifically, I'm from the MetroWest area. A couple people on this list are from the Boston are too: David Lapointe and Rick Ree. I personally felt there was no need to leave the area to find a college. What brought you to Michigan? > Right! The only time you'd have to worry about it is if you were directing > projects or something. Or supporting many research labs (like the harvard > job is asking for). Yeah. Most of the job adds I see ask for someone with (1) a bioinformatics degree (you can count the schools in the world offering such a degree on one hand), (2) a comp sci degree, or (3) a biology degree. Bioinformatics does cross more than 2 fields, I'm afraid. > I'll be staying in downtown boston all weekend; my flight leaves at > 3pm. if anyone in boston feels social, give me an email; if not, talk to > you guys later. I'm leaving now. Really. How long are you staying, until Monday? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Apr 27 09:08:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: <3908358C.D270697B@geoserve.net> <3908289C.8A091073@casema.net> Message-ID: <39083BC2.A4A38EFE@geoserve.net> jarl van katwijk wrote: > > Maybe somebody can give me some URL to a site that's explaining what > the definition of 'bioinformatics' is? More than one link: http://lycospro.lycos.com/srchpro/?aloc=sb_init_content&first=1&lpv=1&query=What+is+bioinformatics&t=phrase&type=advwebsites&x=31&y=11 Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu Apr 27 09:04:32 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Re: [Pipet Devel] piper Message-ID: <200004271306.JAA126580@archa11.cc.uga.edu> > The vote is... > > Jeff: YES > Jean-Marc: YES > Jarl: YES > (Deanne: YES) > > Still missing: > > Brad Shore. Count me in. But only if we only refer to the definition layer as Piper at the Gates of Dawn... > Flower^H^H^H^H^H^HGary: I'll stick up for Gary (along with Jennifer) and say that DataFlower was my favorite name :-) I guess us Botanists are all biased, tho. Brad From jarl at casema.net Thu Apr 27 08:13:50 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: <3908358C.D270697B@geoserve.net> <3908289C.8A091073@casema.net> <39083BC2.A4A38EFE@geoserve.net> Message-ID: <39082EFE.906115AB@casema.net> > > Maybe somebody can give me some URL to a site that's explaining what > > the definition of 'bioinformatics' is? > > More than one link: > > http://lycospro.lycos.com/srchpro/?aloc=sb_init_content&first=1&lpv=1&query=What+is+bioinformatics&t=phrase&type=advwebsites&x=31&y=11 You'd agree when I say Bioinformatics is the biology term of what is more generally called Complexity? From bizzaro at geoserve.net Thu Apr 27 09:31:12 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: <3908358C.D270697B@geoserve.net> <3908289C.8A091073@casema.net> <39083BC2.A4A38EFE@geoserve.net> <39082EFE.906115AB@casema.net> Message-ID: <39084120.CA1AE119@geoserve.net> jarl van katwijk wrote: > > You'd agree when I say Bioinformatics is the biology term of what is more generally called Complexity? Hmmm. That's a new one to me. Are you talking about complexity in math or comp sci or what? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From rree at oeb.harvard.edu Thu Apr 27 09:15:58 2000 From: rree at oeb.harvard.edu (Rick Ree) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc In-Reply-To: <3908376A.D0FB355D@geoserve.net> Message-ID: On Thu, 27 Apr 2000, J.W. Bizzaro wrote: > "J.W. Bizzaro" wrote: > > > > Tell me about it. As if there are sooooo many Ph.D. programs in > > bioinformatics out there! Personally, I think computer skills are more > > important than having a pure (non biochem or biophysics) background. You > > usually focus on a single biological problem in bioinformatics, so there can > > be less biology to learn than computing/programming. > > "Pure" biologists are such snobs when it comes to the allied fields. I can > attest to that in my many failed attempts to cross over from chemistry. But > don't get me going on that...I want to keep people ON this list :-) Sorry you've had negative experiences. BTW I'll only tolerate 2, maybe 3 hundred more disparaging remarks about 'pure' biologists before leaving in a huff :) What kind of cross overs were you attempting? Rick From jarl at casema.net Thu Apr 27 08:38:03 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: <3908358C.D270697B@geoserve.net> <3908289C.8A091073@casema.net> <39083BC2.A4A38EFE@geoserve.net> <39082EFE.906115AB@casema.net> <39084120.CA1AE119@geoserve.net> Message-ID: <390834AB.1AACBF95@casema.net> > > > > You'd agree when I say Bioinformatics is the biology term of what is more generally called Complexity? > > Hmmm. That's a new one to me. Are you talking about complexity in math or > comp sci or what? In the definition the people of the SFI (http://www.santafe.edu/) do, 'Emerging Science', nothing can be seen standalone, it's all part of a system. From deanne at density.biop.umich.edu Thu Apr 27 09:52:17 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc In-Reply-To: Message-ID: > > > > "Pure" biologists are such snobs when it comes to the allied fields. I can > > attest to that in my many failed attempts to cross over from chemistry. But > > don't get me going on that...I want to keep people ON this list :-) > > Sorry you've had negative experiences. BTW I'll only tolerate 2, maybe 3 > hundred more disparaging remarks about 'pure' biologists before leaving in > a huff :) What kind of cross overs were you attempting? > Hi again. Running late. Slow laundry. :) Me, I'm trying to "cross over" from structural/quantum/physical biochemistry into bioinformatics. If there's such a thing as "cross over" there. Baxevanis himself started off as a physical biochemist, so I don't understand the cliquishness I'm experiencing in the field. I have publications, a solid reference group, a nice pedigree as far as education and research experience. What I don't have is the "bioinformatics stamp of approval". Even postdoctoral jobs are being weird. I'm putting my resume below so you can see what I mean about everything I just said. The only thing I can see that I'm lacking is some development package (software) but I'm someone who programs to solve problems lately, so I've been working in FORTRAN. But my experience is pretty far-reaching overall. ---------------------------------------------------------- Objective Biophysical scientist with extensive computing, technical, administration, teaching, and communication experience seeks challenging position in structural bioinformatics, computational biology, and/or other interface between molecular biology, biological sciences, and computing. Education Present: Ph.D. candidate, Biophysics Graduate Program University of Michigan, Ann Arbor, MI. Expected date of Ph.D. Degree Completion: July/August 2000 April 1997 Masters of Science in Biophysics University of Michigan, Ann Arbor MI June 1995 Bachelor of Arts, Double Major: Physics, Astronomy Wellesley College, Wellesley, MA June 1991 Associate of Arts (Honors) North Shore Community College, Lynn, MA. High School: Our Lady of Nazareth Academy, Wakefield, MA. Publications D. M. Taylor and A. Ramamoorthy "Analysis of Dipolar-Coupling Mediated Coherence Transfer in a Homonuclear Two-Spin-1/2 Solid-State System." Journal of Magnetic Resonance, 141, 18-28 (1999) D. M. Taylor and A. Ramamoorthy "Analysis of Dipolar-Recoupled Coherence Transfer in MAS experiments of a Homonuclear Two-Spin-1/2 Solid-State System " (in review) J. Brender, D. Taylor and A. Ramamoorthy "Optimization of Ab Initio Calculations for NMR Tensor Orientations in Peptides" (in review) Research Experience 1/97-present University of Michigan Dr. A Ramamoorthy Chemistry/Biophysics Synopsis: Solid-state NMR theory of dipolar coherence transfer among multiply-labeled spin sites in membrane proteins, and quantum chemical calculations of NMR parameters. Membrane proteins, whose structures are notoriously difficult to study using normal structural biology techniques (solution NMR, x-ray crystallography), can be studied using NMR in the solid state (SSNMR). SSNMR has several challenges which need to be addressed before successful experimental algorithms can be developed to yield useful protein structural information without prohibitive cost or time investment. My research is directed towards using quantum physics and information theory to develop optimal experimental conditions and analytical solutions for information transfer between two or more atoms of the same element (carbon-carbon, for example). The strongest exchange process in SSNMR which both prevents finely resolved spectra yet at the same time provides distance information (r) is the dipolar interaction, which is a strong coupling interaction that acts as 1/r3 . One of the biggest obstacles to the use of SSNMR to solve complex structural biology problems is the understanding, at the quantum level, of how atoms exchange distance information, in our case, carbon-13 atoms in a peptide backbone. This research is particularly relevant to protein samples that have some limited or extensive aspect of diffusional and spatial randomness, such as experienced in proteins integrated into artificial membrane planes, or those in bicelles (small elliptical "pieces" of bilayer membrane). Before this work, it was not known how information exchange would travel through space between carbon backbone atoms in a randomly aligned population of proteins to other spatially proximate but not necessarily directly bonded peptide carbons. After solving the quantum-mechanics equations for information exchange between the peptide carbons, I have simulated, using computer programs, models of the transfer of distance information among peptide backbone carbon atoms. The programs' outputs give the coherent evolution of information exchange over time, frequency, and distance in the quantum spin operators under various experimental conditions for both oriented (crystalline) and unoriented (powder) samples of small proteins and peptides. During the course of my investigations, I have discovered a significant deviation from the simplest predicted models by including scalar coupling effects previously thought insignificant within the peptide unit, as their effects are only two percent of the total coupling, but convoluted over the experimental time of milliseconds, evolution frequency patterns deviate twenty percent or more in phase (and therefore in immediate magnitude). This means that it may be possible to isolate out directly-bonded carbon atoms in a two-dimensional spectrum by examining the phase behavior. It has been established experimentally that high-resolution spectra can be gained by using a method called magic angle sample spinning (MAS) which removes the strong coupling of the dipolar interaction, but loses the distance information as well. However, application of certain multipulse sequences can recouple some of that distance information (dipolar recovery experiments). I have derived the average Hamiltonian for several dipolar-recovery experiments published by other groups (DRAMA, USEME, DRAWS, SEDRA) and worked on solving their particular dipolar coherence transfer. I have determined how the distance information is transferred in the unoriented population in each experiment and have solved the equations of maximal magnetization transfer velocity (distance versus time) as well as sample-dependent transfer (dipolar coupling constant versus time), and established the effects of intra- as well as inter-peptide information exchange, the effects of bonding on distance exchange, and am currently finishing work on adding offset parameters to account for deviation in chemical shifts between the carbons of the peptide plane. At that point, I am confident I can match my results with experimental structure, obtaining, for the first time, analytical equations that can accurately predict the information exchange among the proximate carbons of a folded membrane protein. My secondary project is again interested in solving structures of proteins using NMR, this time calculating the orientations of the peptide plane in respect to the laboratory frame, gathering information in this way on the absolute orientation of the planes to one another. This is done through simulation of chemical shift (NMR) tensor orientations of small proteins on several platform ab initio (quantum chemistry) packages such as Dalton, deMON, Gaussian98, and NWChem. However, modeling NMR experimental constraints must also take into account special factors, such as the contribution of the magnetic field within the magnet to the behavior of the electron orbitals, the accuracy of our basis sets and methods, and our choice of compounds and initial conditions. We have a paper in review which will publish optimized methods for calculation of these experimental constraints so that protein structure or protein-ligand interaction can be solved. 5/96-12/96 University of Michigan Dr. Noemi Mirkin Physics/Biophysics. Synopsis: Ab initio calculations of dipeptide structure and bond energies * Calculations of minimum energy conformers of pentane and various conformations of a blocked glycine dipeptide, * Creation of peptide bond rotation energy curves/surfaces. * Established benchmarks for computational efficiency for various GAUSSIAN ab initio computational routines on available hardware * Determined relative energies of glycine dipeptide in several conformations found in larger proteins. 01/96-05/96 University of Michigan Dr. W. Richard Dunham Biophysics Synopsis: study of cobalt-ligand electronic bonding in wildtype vitamin B12-dependent methionine synthase and mutants using EPR and quantum mechanics. * Using software developed in the Dunham Lab, I matched experimental EPR spectra of cobalt in B12-dependent methionine synthase and mutants with software-generated models to establish symmetric changes around the cobalt atom between the mutants and the wildtype. * Discovered significant deviations in the A-tensor strain from the spectral parameters, proving that there exists a difference from the traditional models of the symmetric structure of fifth and sixth ligands and possibly of the corrin ring. * Discovered indications that chemical bonding may occur between the cobalt atom and the fifth and sixth ligands through an s-orbital rather than a d-orbital, by establishing that a significant change exists in the Fermi contact term between the cases of base-on and base-off (fifth ligand) mutants of methionine synthase. * Performed associated molecular biology/biochemistry laboratory experiments, including expression and purification of protein and mutants. 9/94-5/95 Wellesley College Dr. Wendy Bauer Astronomy Synopsis: Characterization of a binary star's unusual emission/absorption UV spectra. * Using data obtained from the International Ultraviolet Explorer satellite, the unusual dynamic behavior of the spectrum of VV Cephei, a long-period binary system, was studied. * Utilized off-site spectroscopic databases by authoring FORTRAN routines to process the raw IUE satellite data into useable format. * Wrote programs to process and analyze spectra, including addition, multiplication, subtraction and division of UV satellite spectra. * Helped determine that the anomalous spectra are a convolution of two spectral effects not previously encountered, due to emission from the smaller hot secondary and molecular absorption of a cooler dust cloud from the cooler primary giant. 5/93-8/93 Stanford Linear Accelerator Dr. Elliot Bloom USA satellite project. Synopsis: Determination of surface reflection properties of a satellite copper collimator. * Tested copper material sample using a single X-ray wavelength. * Was able to establish the non-reflectivity of the copper foil at low angles to all X-ray wavelengths based on Maxwell's equations, proving its suitability for use in the satellite experiment. * Produced an official report to the records of the government-funded project, establishing that the material was suited for the satellite system. May-August 1992 Wellesley College Dr. R. Berg Physics Synopsis: Installation/Design of a Solar Zeeman Effect spectroscopy system. * Designed an on-board photon counting system as well as a cooling/refrigeration system to be used with a high-resolution 1-meter optical spectrometer. * Designed and installed optics at a nearby observatory to be used with a fiber optic network running between the solar collector and the spectrometer. * Built circuit boards and programmed photon counting system in BASIC over IEEE interface between a lock-in amplifier and a personal computer. 1991-1993 Massachusetts Institute of Technology Dr. Wade Sapp Bates Linear Accelerator Synopsis: Optimization and installation work on a new electron beam storage ring. * Large dipole magnet placement and dipole/quadrupole/octupole magnet field mapping, survey work, test equipment design, computational calculations of higher field moments of magnets. * Optimization calculations for beam placement. after higher moments were determined on the Linac's VAX system . Awards, Fellowships 2000 University of Michigan Outstanding Graduate Student Instructor Award 1999 Graduate Student Instructor Award , University of Michigan Chemistry Dept. 1998 1999 Sloan Foundation Fellowship, U of M 1997 Margaret Dow Towsley Scholarship, U. of Michigan 1995 Sigma Xi Science Honors Fraternity 1991 Henry Cabot Lodge Scholarship 1991 Association of American University Women Scholarship 1991 USA Today All-American Academic Team Award 1990 Phi Theta Kappa Honors Fraternity Significant Coursework * Mathematics: Complex Variables. Calculus 1, 2, 3. Group Theory. Linear Algebra. Differential Equations. Analysis. * Biophysics: Principles of Magnetic Resonance. Advanced Topics (crystallography, NMR, Thermodynamics, Protein Folding). Microscopy. Dynamic Processes in Biophysics. Protein Structure & Dynamics. Physics of Macromolecules . * Physics: Quantum Mechanics. Quantum Theory. Applied Quantum Laboratory. Electrodynamics. Nonlinearity/Chaos/Complex Systems. Mechanics. Thermodynamics and Statistical Mechanics. Waves and Vibrations. Electronics and Circuit Design. * Chemistry: Organic Chemistry I, II. General Chemistry I, II. * Astronomy: Observational Techniques I+II. Advanced Astrophysics I+II. Stellar Astronomy. Planetary Astronomy. * Biochemistry and Molecular Biology: Protein Trafficking. Signal Transduction. Metabolic Regulation. Molecular Cell Biology. Protein/Nucleic Acid Interactions. Nucleic Acids. Gene Expression. Biochemistry. Methods in Molecular Biology . * Pharmacology: Methods of Computational Chemistry . Associated Skills * Programming: FORTRAN, C++, some familiarity with Perl, and some Java. * WWW: HTML, JavaScript, and php3 * Software (high proficiency): Adobe PhotoShop, Adobe Illustrator, MS Word and various other WP, MS Excel, Mathematica, Maple V, Gaussian, various quantum chemistry packages, many GNU packages (gnuplot, gcc, gnu make, etc.), GNOME, XFREE86, exposure to programming with message passing for parallel computing libraries (MPICH), scientific libraries (BLAS, etc), many others. * Database: mySQL, FileMaker, Microsoft Access, some FoxPro * Operating systems Linux, IRIX, Unix, Solaris, MacOS, Windows95, 98, NT, X windows, some VMS. * Molecular Biology/wetlab: Protein Expression protocols, Purification (HPLC, gels, columns), PCR, training in ELISA, Northern, Eastern. Protein crystallization. Also inorganic lab experience. Employment Outside of Research 9/97-Present University of Michigan Biophysics Program Systems Administrator * Systems Administrator for a physical chemistry/biophysics laboratory specializing in computer modeling, molecular simulation, quantum chemistry calculations, and quantum computing. * Management of a 20-machine networked cluster of multi-user machines, including SGI (Octane, O2), PC-clones (single and multi-processor), Macintosh, and Suns, with the following OS: Irix, Solaris, Linux, MacOS, Windows 9X/NT and Unix. * Starting from scratch, built an integrated and smoothly functioning computer simulation and scientific support laboratory environment over three years, much of which is multiuser Linux, NT, Win98 and Irix. * Assembled inexpensive but powerful Linux multiprocessor servers from components to run quantum mechanical simulations using MPI libraries. * Installed, supported, and utilized several proprietary software packages as well as freeware/shareware/commercial packages for quantum chemical calculations (such as DALTON, deMON, Gaussian98, GAMESS). * Performed analyses of quantum-chemistry software performance cross-platform and cross-package. * Installed and supported software and upgrades for applications on all platforms such as web servers and associated engines (apache, php3), database programs (mySQL), gnu and other freeware applications (GAMMA, make, Tex, gnuplot, XFREE86, GIMP, etc). * Maintained programming libraries and compilers (gcc/g77, libc, tk, various scientific libraries, etc), operating systems and kernel upgrades, multi-processor programming libraries (mpich), commercial applications (Mathematica, Maple, Adobe, Microsoft), security (ssh, system security optimization). * Supplied ready user support for all software packages. * Performed scheduled hardware and network maintenance/swapouts, such as for disk drive, memory, and processor upgrades, tape backups, troubleshooting, diagnosis and repair. 5/99 - Present Versity.com Expert Consultant Astronomy and Chemistry knowledge Expert. * Provided college student questions online with excellent reviews. * Crafted extensive expert knowledge database trees in several science fields. * Performed helpful quality control on student note submissions. * Researched nationwide college programs and textbooks for inclusion in student help center. * Provided web links and scientific definitions for databases. * Strengthened the company's intellectual product. 5/99-10/99 University of Michigan Educational and Tech Consultant Office of the VP for Student Affairs Curriculum Infusion Project * Co-designer and creator of a program teaching Teamwork and Leadership to professionally-bound college students (engineers, scientists, etc) in areas such as: Active Listening, Effective Meetings, Communication, Accountability, Stages of Team Development, Team Building, Self-Awareness, Multiple Perspectives, Goal-setting, Being Proactive, Time Management, Trust-Building. * Part of team that designed the Michigan Team System that utilized these skills in a set format for the introduction of a sample, standard operating agreement for group meetings across the University of Michigan. * Co-author of student and faculty manuals on teamwork and students' personal development, especially in the areas of Accountability, Multiple Perspectives, Self Awareness, Team Building, Being Proactive; also wrote faculty research documents on "Effective Assessment of Student Team Performance" and "Establishing Accountability Among Members of Student Teams." * Development of self-assessment and faculty assessment tools to be used in classrooms. * Development of web tools for knowledge delivery with php3 and mySQL. * Design and creation of all of the project's PowerPoint presentations, graphics, slides, and plots to be presented to University officials and administrators. * Delivery and customization of materials for various University courses involved in the project, including adaptation for Chemistry and Mathematics. * Provided leadership and work ethic which served as a major impetus for the project. * Acted in a leadership position to bring the project's products to completion within 4 months including a 80-page student manual and a 100-page instructor's manual, as well as presentations and teaching material designed specifically for participating instructors. 9/98-present coLABnet Project, funded by National Science Foundation Tech and Education Consultant University of Michigan * Team member on an National Science Foundation funded project that assists first year chemistry students by allowing them to collaborate in gathering and analyzing individual laboratory observations on a inter-lab system of 18 iMacs networked to a Macintosh G3 server and printers. * Creation of software report outputs and data-seeding system using advanced Excel database analysis and FoxPro. * Configured experiments for student use. * Troubleshooting of new modules and interface, diagnosis and bug repair. * Technical support and instructor training, software installation, system/software interface support, and system/network support. * Contributions of new ideas to enhance the collaborative environment. * Took major role in installation and system implementation. * The coLABnet Project won a Smithsonian Innovation Network Award. Teaching Experience/Employment 9/96-Present University of Michigan Graduate Student Administrator/Manager Chemistry Department * Supervised a team of graduate students teaching a large Chemistry laboratory course at the University of Michigan. * Programmed and administered a course-wide gradebook for up to 20 instructors and 40 course sections using advanced Excel macros and database analysis. * Analyzed and normalized grading curves and grading trends, held review sections, assisted professors and developed new materials to enhance the coursework. * Oversaw other administrative details such as web posting of answer keys, worksheets, and the smooth functioning of course software. 9/96-1/99 University of Michigan Graduate Student Instructor Physics and Chemistry Departments * Taught introductory physics laboratory and chemistry laboratory to college-aged students, facilitated student-run discussions, graded coursework, developed experimental procedures, trained students in the use of equipment and computers. * Regularly received high rankings by students for teaching excellence in course evaluations. * Received a Teaching Award through the Chemistry Department. * Honored with the year 2000 University of Michigan Outstanding Graduate Student Instructor Award. From bizzaro at geoserve.net Thu Apr 27 10:51:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: <3908358C.D270697B@geoserve.net> <3908289C.8A091073@casema.net> <39083BC2.A4A38EFE@geoserve.net> <39082EFE.906115AB@casema.net> <39084120.CA1AE119@geoserve.net> <390834AB.1AACBF95@casema.net> Message-ID: <390853DC.ECA451E9@geoserve.net> jarl van katwijk wrote: > > In the definition the people of the SFI (http://www.santafe.edu/) do, > 'Emerging Science', nothing can be seen standalone, it's all part of a system. Well, bioinformatics is multidisciplinary science, invloving just about all of the allied fields of comp sci, biology, chemistry, physics, math and engineering. It's about as 'cutting edge' as you can get. But the word is simply the combination of the 2 words... biology + informatics and literally means, "information technologies for biology". Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From stein at fmnh.org Thu Apr 27 11:51:23 2000 From: stein at fmnh.org (Jennifer Steinbachs) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Complexity In-Reply-To: <39084120.CA1AE119@geoserve.net> References: <3908358C.D270697B@geoserve.net> <3908289C.8A091073@casema.net> <39083BC2.A4A38EFE@geoserve.net> <39082EFE.906115AB@casema.net> <39084120.CA1AE119@geoserve.net> Message-ID: <200004271551.KAA20811@mail.fmnh.org> Quoting "J.W. Bizzaro" : > jarl van katwijk wrote: > > > > You'd agree when I say Bioinformatics is the biology term of what is more > generally called Complexity? > > Hmmm. That's a new one to me. Are you talking about complexity in math or > comp sci or what? Aren't they more or less the same? For what it is worth, I'm sitting in a class (call it "guest student") on bioinformatics offered through comp sci at U of Chicago. It has been quite amusing so far... Ever listen to computer scientists try to teach other computer scientists about protein transcription and translation? :) This course is more focused on teaching algorithms for different aspects in bioinformatics (mostly sequence analysis), so I also keep hearing the phrase "well, it's actually messier than that..." I think the plan was originally to stay focused on deterministic solutions, until I spoke up and pointed out that probabilistic methods are making great in-roads (HMMs, Bayesian estimation, etc.), and so this week included a real hand-wavy lecture about Markov chains and HMMs: "You use a subset of the data to make your probability estimates from which you build your model and then extrapolate to larger datasets." Quite an original explanation. Cheers, -j ------------------------ J. Steinbachs, PhD Computational Biologist Dept Botany The Field Museum Chicago, IL 60605-2496 312-665-7810 312-665-7158 (fax) http://cb.fmnh.org ------------------------- From gvd at redpoll.pharmacy.ualberta.ca Fri Apr 28 02:23:59 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Re: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> <39082CD3.1931C8F4@geoserve.net> Message-ID: <39092E7F.B0491F0E@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > Still missing: > > Brad: > Flower^H^H^H^H^H^HGary: Considering the Dutch translation, I think its super ;-). Regards, g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From gvd at redpoll.pharmacy.ualberta.ca Fri Apr 28 03:11:07 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc References: Message-ID: <3909398B.3E0D4E6F@redpoll.pharmacy.ualberta.ca> deanne@density.biop.umich.edu wrote: > > Me, I'm trying to "cross over" from structural/quantum/physical > biochemistry into bioinformatics. If there's such a thing as "cross > over" there. Baxevanis himself started off as a physical biochemist, so I > don't understand the cliquishness I'm experiencing in the field. I have > publications, a solid reference group, a nice pedigree as far as education > and research experience. What I don't have is the "bioinformatics stamp > of approval". Perhaps you should include your association with The Open Lab in your curriculum vitae. It certainly hasn't hurt mine :-). Actually I'm surprised you're getting attitude, your cv looks pretty solid to me. Regards, g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From jarl at casema.net Fri Apr 28 05:07:40 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Complexity References: <3908358C.D270697B@geoserve.net> <3908289C.8A091073@casema.net> <39083BC2.A4A38EFE@geoserve.net> <39082EFE.906115AB@casema.net> <39084120.CA1AE119@geoserve.net> <200004271551.KAA20811@mail.fmnh.org> Message-ID: <390954DC.23660FF6@casema.net> > > > You'd agree when I say Bioinformatics is the biology > term of what is more > > generally called Complexity? > > > > Hmmm. That's a new one to me. Are you talking about > complexity in math or > > comp sci or what? > > Aren't they more or less the same? > Yes. And you can add physics and economy to this list too. If you are willing to. It's all just another level of approach. From deanne at density.biop.umich.edu Fri Apr 28 20:25:11 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc In-Reply-To: <3909398B.3E0D4E6F@redpoll.pharmacy.ualberta.ca> Message-ID: > > Perhaps you should include your association with The Open Lab in your > curriculum vitae. It certainly hasn't hurt mine :-). Actually I'm > surprised you're getting attitude, your cv looks pretty solid to me. Eh, when I actually contirbute something, I'll take my bows. :) News from the job front. The harvard job rocks. I was told basically that I would be able to "create" the position myself. I'd still be just a research scientist, but I can actually "create" my value to the med school by by defning mwhat my job description is. They don't knowwhat they need, only that they need it, and I think they'll give me the job ...don't know if'm "worthy"...but I love every single person I met so far. Nice, professional, enthusastic people. I would essentially be helping various labs figure out what they need in bioinformatics while I do my own research on the side. It's like a dream job to me. I have ideas for enzyme networks and stuff. Want to do more of that. Okay, still in hotel room. Thanks for the kind words. Back home on Sunday then more python. :) With regards, Deanne From gvd at penguin.pharmacy.ualberta.ca Sat Apr 29 03:15:10 2000 From: gvd at penguin.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Job interviews, etc In-Reply-To: Message-ID: On Fri, 28 Apr 2000 deanne@density.biop.umich.edu wrote: > > > > Perhaps you should include your association with The Open Lab in your > > curriculum vitae. It certainly hasn't hurt mine :-). Actually I'm > > surprised you're getting attitude, your cv looks pretty solid to me. > Eh, when I actually contirbute something, I'll take my bows. :) > > > > News from the job front. > > The harvard job rocks. I was told basically that I would be able to > "create" the position myself. I'd still be just a research scientist, but > I can actually "create" my value to the med school by by defning mwhat my > job description is. They don't knowwhat they need, only that they need it, > and I think they'll give me the job ...don't know if'm "worthy"...but I > love every single person I met so far. Nice, professional, enthusastic > people. I would essentially be helping various labs figure out what they > need in bioinformatics while I do my own research on the side. It's like a > dream job to me. I have ideas for enzyme networks and stuff. Want to do > more of that. Congrats, and keep us Boston-bound bunch in mind if new positions open up ;-) Regards, g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From chapmanb at arches.uga.edu Sat Apr 29 09:30:15 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] Random design thoughts Message-ID: Hello all! I've been doing a lot of thinking about the design of Loci/VSh/Piper, and especially about the ideas Jeff has had about combining the middle (dl) and front (ui) back together. In thinking about this, I was trying to kind of find some good models to look at the might have also tried the approach of having the user interface separated from the main functionality of the program through a communication layer. In our case, we are currently using a streaming XML dialog to separate these two layers. In my opinion, this approach is really cool because it provides us the ability to have multiple user interfaces in any language imaginable. So anyways, in my searching I started taking a look at the Berlin project (http://www.berlin-consortium.org) and think its kind of interesting that they use a similar separation of processing from user interface. If you check out http://www2.berlin-consortium.org/wiki/html/Berlin/HowBerlinUsesCORBA.htm, they have a terse description of this separation. Although they use CORBA (and not sockets like we have) the basic design seems to be the same--looking at it from our perspective the front (ui) makes calls to the middle (dl) to modify an xml description of the user interface, and then return info back upon completion of the modification. I just thought this might be good food for discussion, as it is kind of cool to me to see a really similar model... Also, if anyone is interested, there is a redesigned dl (middle) in cvs along with documentation (yay!) on the new structure of the code and on the overall design plan for the dl in general. Comments are more than welcome :-) The immediate plan for the middle (dl) is connection with gms (the bl) so we'll see how that goes... Thanks for listening. Brad From rree at oeb.harvard.edu Sat Apr 29 11:28:47 2000 From: rree at oeb.harvard.edu (Rick Ree) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] good MVC design reference? Message-ID: Can anyone point me to a good reference book/paper on the model-view-controller design paradigm? Especially one that's non-language-specific, and online. Thanks, Rick From chapmanb at arches.uga.edu Sat Apr 29 12:34:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:31 2006 Subject: [Pipet Devel] good MVC design reference? Message-ID: <200004291636.MAA89176@archa10.cc.uga.edu> > Can anyone point me to a good reference book/paper on the > model-view-controller design paradigm? Especially > one that's non-language-specific, and online. Thanks, Rick; I read about this a while back just because I saw a reference to it somewhere and was curious, and I found a pretty good tutorial on Cristobal Baray's page at: http://www.cs.indiana.edu/~cbaray/projects/ mvc.html. He uses Java for a small example applet (which I think is easier to understand then all of the Smalltalk examples), but a lot of it is a pretty language non-specific and talkative, which I liked. Thanks for reminding me about this design pattern, I hadn't thought about it in a while :-) Brad From chapmanb at arches.uga.edu Sun Apr 30 15:48:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:32 2006 Subject: [Pipet Devel] Fun with ORBs Message-ID: <200004301950.PAA78636@archa11.cc.uga.edu> Hello all; I've been workin' on setting up Loci to talk with GMS though a corba interface. I've been attempting to use orbit-python (http://projects.sault.org/orbit-python/) so we could stay with one ORB implementation (ORBit) for the whole project. However, now that I have gotten into actually using these bindings, I'm running into a huge snag. The problem is that you can only import the idl file (orbit-python uses this instead of generating stub and skeleton code that you import) in the __main__ module, so things will only work if you are running a simple program in a main script. This is a known deficiency of orbit-python (ie. mentioned on the TO-DO list), and prevents us from using orbit-python to do what we want to do. I spent some time looking at the code and comparing it to CORBA::ORBit (the perl bindings to ORBit, which implement a similar idl import method) and I don't really see a simple fix for this problem at all. The orbit-python project is also stalled (no new code in a month and a half) so I'm not sure how things will progress there... So, I'm going to have to switch to a new ORB implementation for the python part of the program so we can have something functional and I wanted to try and get people's opinion on which ORB we should switch to for python. Here are the choices: Fnorb (http://www.fnorb.org/). ----- Advantages: o Easy to install becuase it is almost all python. Disadvantages: o Doesn't follow the official OMG python mapping (http://www.omg.org/cgi-bin/doc?ptc/00-01-12) so it'll require code changes later (not too big a deal for clients, but more of a pain for servers). o Pretty slow because of all the python. o I think the license is for non-commerical use only. ILU (ftp://ftp.parc.xerox.com/pub/ilu/ilu.html) ---- Advantages: o Has both C and python bindings, so if we wanted to we could switch to using only ILU. o Has a compatible license (I'm pretty positive about this--they've changed it since the problem with gnome or whatever). Disadvantages: o Their implementation of the official python mapping in the latest release isn't quite correct due to mistakes in the OMG document, so this will require some code changes later. omniORBpy (http://www.uk.research.att.com/omniORB/omniORBpy/) --------- Advantages: o Follows the official mapping. o Supposedly pretty fast. o Has a compatible license (LGPL or GPL, your choice). Disadvantages: o Can be a pain to install (at least for me :-). So anyways, those are our choices. What does everyone think about all of this? I'd really like to hear everyone's opinion about what we should do. Thanks for listening. Brad From chapmanb at arches.uga.edu Sat Apr 1 11:36:31 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:41 2006 Subject: [Pipet Devel] locus vs. node naming Message-ID: <200004011639.LAA43502@archa12.cc.uga.edu> > Brad Chapman wrote: >> Can we either use "locus/loci" in the definition layer, or think >> up a new term that won't clash with DOM so much? Jeff wrote: > This is a 'simple' namespace problem, which can usually be solved by > appending > the application's name. So, instead of 'node', you can use... > > vshnode Well, I wasn't so worried about the namespace problem as the problem with clarity of code. For instance, let's take this current snippet o' code from the middle: middle_node = dom_tree.createElement('middle') dom_tree.appendChild(middle_node) success_node = dom_tree.createElement('success') middle_node.appendChild(success_node) locus_node = dom_tree.createElement('locus') locus_node.setAttribute('id', locus_id) locus_node.setAttribute('num_inputs', str(num_inputs)) locus_node.setAttribute('num_outputs', str(num_outputs)) locus_node.setAttribute('gui_name', gui_name) success_node.appendChild(locus_node) I think you can see the problem if I started referring to a locus as a dlnode (dlnode_node = ...). The additional problem is that I am redoing the middle code and am thinking of organizing the loci structure in a DOM-like manner. Ie. loci can have parent loci (the container or composite locus holding them) which will make things additionally confusing. I just want to see the code be as clear as possible and the node/node stuff is confusing, IMO. > BTW, about the BL nodes, I was thinking that since these always have an > Internet location, they could be referred to as a node of type 'locus'. I'm confused by what you are talking about here. Do you mean the 'GMS' layer? Brad From chapmanb at arches.uga.edu Sat Apr 1 12:24:16 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Choice of ORB implementations Message-ID: <200004011726.MAA61350@archa11.cc.uga.edu> Hello all; Since we are starting to get into CORBA stuff (Jarl and I are going to start working soon on the defintion layer to brokering layer CORBA implementations) I wanted to discuss about what ORB implementation(s) we should be using to design this system. I guess there are two big competitors, omniORB and ORBit. From what little I know about speed, these seem to be fast compared to other freely available implementations, and both seem to be compliant with licensing (from what little I know about that as well). However, I think we have some problems if we decide to go with either of this independently. Let me give the point by point on the things I'm thinking of. If I am being idiotic on any of the following, please call me out :-) 1. Bindings: From what I figure, we should need C and python bindings for the ORB we use. ORBit, of course, is all about C, and has python bindings under development (but still quite early in development). omniORB has really nice python bindings, but does not have C bindings as far as I know, which is a serious problem. Advantage: ORBit 2. Threading: I've been trying to read up and learn as much as I can about CORBA since I'm really green with it, but still want to implement a good distributed system like we need here. Thinking about what our needs will be for talking between definition layers (more on this in my next post), I think a multithreaded server implementation will be a good way to go. I still have a lot to learn about threading, but for what I have played with on the current middle I like python's threading support and from my reading I like the setup of a threaded server. omniORB has support for multithreaded servers, and from what I can tell from the list server it has been tested in a number of application. From reading the ORBit to-do list, it seems like thread safety is not yet implemented (although I hope I can be proven wrong on this). Advantage: omniORB 3. Naming service: It seems like using the naming service might be a good bet for maintaining a list of available VSH implmementations (I think Jeff has described this before as a kind of domain name service that maps vsh implementations to their names (ie. Jeff's computer)). As far as I can tell, both ORBit and omniORB have good naming service support, but I don't know enough about it to say more. Advantage: tie (because I am too uninformed to make a decision :) Alright, that is my list for now. I'm throwing this out because I really want to hear people's opinions, not because I am at all an expert on this stuff. I'm just trying to think through this and would like everyone's help. So: Are there considerations we should be taking into account? Are there other orb implementations we should be considering? Does anyone see a workaround for the threading and binding problems I mention above? How can we reconcile this? Do we need, ugh, two ORB implementations? Other ideas on this? Thanks for listening. Brad From chapmanb at arches.uga.edu Sat Apr 1 12:58:16 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] summary for web Message-ID: <200004011800.NAA116848@archa10.cc.uga.edu> [snip... my 8 step idea for node sharing between remote location] Jarl wrote: > If you want to accomplise 1) you do a ReteiveInfo::uriStatus() on the BL. > 5) will work by Representation::upload() Agreed. I think that points 1 through 5 are well taken care of in the idl for dl->bl communication. > What we'll need ain't a DL <-> DL communication line, but a BL -> DL one. > (opposing the DL -> BL commmunication we've described by the > vsh-pilot.idl) > > This way all authentication will remain at one layer, otherwise we'll get > some > serious syncronising problems. > > Please do doubt & discus my opinion! I've been thinking a lot about this and like the idea, and even want to extend it a level to include the following (probably controversial) idea: All communication between vsh implementations at different locations should occur in the definition layer. First let me describe how my 8 step thingy would work under this new idea and then mention what I think are the advantages to this approach. Okay, as before, the first 5 steps would occur, and the definition layer would pass an XML description of a workflow diagram containing a remote node (on Jeff's computer, in my example) to the processing layer. 6. The brokering/processing layers would set up it's path of processing and start processing things. 7. When the information from the remote node is needed, the brokering layer will send a message to the definition layer (through the as-of-now undefined bl->dl idl that Jarl proposed) to send the XML to the remote node for processing. 8. The definition layer on my computer will contact the dl on Jeff's computer and authenticate again. 9. My dl will then send the XML to be processed to Jeff's dl. 10. Jeff's dl will contact Jeff's brokering/processing layer, do the computations, and return the results. 11. My dl will be able to query Jeff's dl about the process of the nodes, and will then fetch them when they are finished, and pass them back to my processing layer. 12. The results will be available on my computer through the dl->bl idl (vsh-pilot.idl) as if they had been executed on my computer instead of Jeff's. Okay dokee, that's my proposal. Let me tell you what I feel are the advantages of this: a. All authentication between remote vsh implementations occurs in one layer, the definition layer (this is the point that Jarl made). b. The processing and brokering layers don't have to worry about networking and can be optimized for maximum processing speed instead of worrying about network connectivity (note: I am not talking at all about "independent" GMS or Overflow programs, which can support any kind of network communication they want, but rather about the communication for vsh). c. This will be an overall speed-up for communication. From reading, it seems like a major cost of communicating across a network is establishing and authenticating the connection. This way we only need to authenticate once and pass one big hunk of data to be processed (the XML description of the node processing to do). In the other scheme I proposed, individual processing nodes would need to transfer information after every process, which could get expensive really fast if you are executing a lot of processes (as for instance, the Overflow guys do). I am assuming that a person would use a non-local node if that processing was expensive or time consuming and they want to: 1. execute expensive code on two or more computer simultaneously or 2. execute the expensive code of a faster computer (or cluster of computers :-). Well, I think that's all of my ranting on this idea. Am I making any sense? Is this idea any good? Criticism is heartily encouraged. Brad From chapmanb at arches.uga.edu Sat Apr 1 20:13:40 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] New corba directory in cvs Message-ID: <200004020116.UAA147228@archa12.cc.uga.edu> Hello all; Jarl and I are starting to get things going with the corba connection between the definition layer and processing layer (the idl that we've been posting on the list). In honor of this special occasion, I imported a new cvs module so we can work on it, and so other people can also check out what's going on (and contribute, if they want :-). The new module is vsh-corba, and is just meant as a test module until this code gets incorporated into our programs. If you go right now there is just the "finalized" format, and a client that I wrote to test everything out. Since the server isn't finished yet, this client isn't even tested on anything yet, but it's there to look at if you want :-). Just wanted to keep everyone up to date on the exciting world o' CORBA... Brad From jarl at casema.net Mon Apr 3 15:28:25 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Access levels in VSH References: <200004020116.UAA147228@archa12.cc.uga.edu> Message-ID: <38E8F0D8.BEAB23ED@casema.net> Hi all, it's too quiet in this mailing list, so I could as well throw this one in: After I put a new pre of gms online, I was doing some more work on the DL to BL communication, which is operational, but in the most basic form thinkable. I discovered Brad and I forgot a set of functions: - dlId authorise(in passwordT password0, in passwordT password) - boolean lockout(in dlIdT dlId, in passwordT password) We needed those to authorize DL's to login. Now this is where my problem begins: who should be able to grant others access? So we need some form of access level in the vsh system, how do we organize them? I copied a 'root' system like unix uses, so only the 1th DL can authorize others. But maybe we do need a more sophisticated system, something that not only allows DL's access, but also grants them the ability to grant access to others. Anyone though about this? ..or is willing to do so now :) bye, jarl From bizzaro at geoserve.net Tue Apr 4 06:01:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] window sill Message-ID: <38E9BD87.43F659AE@geoserve.net> I'm sorry that I've been too quite lately. I'll get back to some messages right away. You may have seen the 'window sill' mentioned on the Loci list. This is pretty much a status bar for the windowlets that appear in the workspace. Attached is a screenshot of one prototype window sill. Below is a description of window sill features and functions. There are 2 basic modes: Shaded and unshaded, which are just like window shading on the Mac and newer Unix WMs, only the BOTTOM of the window (the status bar) remains visible. The status bar is a leeetle bit more informative than the title bar of a window, right? Well, in the true nature of Loci (and now VSh), we're trying to rethink a lot of the 1981 Apple Lisa paradigms that people just can't see beyond. I've been thinking this over and over for days now, BTW. I believe this design gives us the most features for the least number of buttons present on the window sill: ------------------------------------- Unshaded mode: [OCCUPY] [VIEW] [RESIZE] Shaded mode: [INFO] [RESIZE] INFO * Visible only when window is shaded * Button contains a text message for each info item (not context-sensitive help) * Time elapsed while unprocessed * Unprocessed/processing/processed * Location * Help message for window's node (truncated) * (others) * INFO is for what occupies the window pane * Click button1 or button3 to cycle through messages (in different directions) * The only button to be horizontally expandable OCCUPY/UNOCCUPY * Click button1 to make self window pane occupy parent window * Click button3 to unoccupy self window pane from parent window * Window sill also occupies parent's (When I say 'parent', I mean a node that contains a network of nodes, one of which being the node in question.) VIEW * Click button1 or button3 to cycle through views: * GUI view: Gtk (composite) interface * Network normal: Network with icons, links and windows * Network world: Only links shown but for entire network (no scrolling needed). Single-click in workspace switches view back to network normal, focused in area of workspace where clicked (like a zoom feature) * Info view (all messages in single view): * Time elapsed while unprocessed * Unprocessed/processing/processed * Location * Help message for window's node * (others) * Context-sensitive help message: for ONE selected node in window's workspace, not for the window's node RESIZE * Press-drag button1 to resize * When shaded, only the window sill can be resized, and it's resized horizontally * Double-click to shade * Double-click again to unshade * OCCUPY and VIEW buttons not visible when shaded, because these pertain only to what occupies the window pane, which will not be shown * INFO is not visible when window is unshaded ------------------------------ I'd like you to note that NOT A SINGLE WINDOW SILL FEATURE OR FUNCTION CALLS ON THE MIDDLEWARE/CORE. THIS IS 100% GUI! And all of it with no more than 3 buttons visible at once! Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: button-test.xpm Type: image/x-xpixmap Size: 45105 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000404/93a99487/button-test-0001.xpm From bizzaro at geoserve.net Tue Apr 4 08:35:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Re: [Pipet Devel] window sill References: <38E9BD87.43F659AE@geoserve.net> Message-ID: <38E9E17D.F2D19D78@geoserve.net> "J.W. Bizzaro" wrote: > > INFO > * Visible only when window is shaded Brad mentioned to me that users would want to change the name of a node. Thinking about it a bit, the name is probably something we want to put under 'info'. So, maybe the INFO button can stay visible at all times and have the name as the first item. This way, we can remove the node name from under the icon and use just the INFO button. Thoughts? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 4 08:51:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Re: window sill References: <38E9BD87.43F659AE@geoserve.net> <38E9E17D.F2D19D78@geoserve.net> Message-ID: <38E9E55B.AAC03660@geoserve.net> "J.W. Bizzaro" wrote: > > So, maybe the INFO button can stay visible at all times and have the > name as the first item. This way, we can remove the node name from under the > icon and use just the INFO button. Maybe I will have the INFO button visible when the window is unshaded, but I think I'll keep the name on top with the icon. I don't want the name to disappear at any time. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 4 13:23:10 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004011726.MAA61350@archa11.cc.uga.edu> Message-ID: <38EA24FE.5E88B45F@geoserve.net> Brad Chapman wrote: > > 1. Bindings: From what I figure, we should need C and python bindings > for the ORB we use. ORBit, of course, is all about C, and has python > bindings under development (but still quite early in development). > omniORB has really nice python bindings, but does not have C bindings > as far as I know, which is a serious problem. What is omniORB written in then? C++? > 3. Naming service: It seems like using the naming service might be a > good bet for maintaining a list of available VSH implmementations (I > think Jeff has described this before as a kind of domain name service > that maps vsh implementations to their names (ie. Jeff's computer)). And the actual nodes contained therein. We need a directory service of a sort. > Are there considerations we should be taking into account? My big concern is licensing. But I guess both are GNU L/GPL, right? > Are there other orb implementations we should be considering? Not that I know of. > Does anyone see a workaround for the threading and binding problems I > mention above? How can we reconcile this? Do we need, ugh, two > ORB implementations? Definitely not. Being partial to Gnome, and considering how much Gnome/Gtk is being used already, I'd prefer ORBit. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 4 13:26:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] summary for web References: <200004011800.NAA116848@archa10.cc.uga.edu> Message-ID: <38EA25C4.7F8A991E@geoserve.net> Brad Chapman wrote: > > Well, I think that's all of my ranting on this idea. Am I making any > sense? Is this idea any good? So that is your summary for the web? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 4 13:49:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] New corba directory in cvs References: <200004020116.UAA147228@archa12.cc.uga.edu> Message-ID: <38EA2B2E.F518DB1B@geoserve.net> Brad Chapman wrote: > > The new module is vsh-corba, and is just meant as a test module > until this code gets incorporated into our programs. Did you decide on which orb to use? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 4 13:57:32 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Access levels in VSH References: <200004020116.UAA147228@archa12.cc.uga.edu> <38E8F0D8.BEAB23ED@casema.net> Message-ID: <38EA2D0C.810E8BE7@geoserve.net> jarl van katwijk wrote: > > We needed those to authorize DL's to login. Now this is where my problem > begins: who should be able to grant others access? > > So we need some form of access level in the vsh system, how do we > organize them? I copied a 'root' system like unix uses, so only the 1th DL > can authorize others. But maybe we do need a more sophisticated system, > something that not only allows DL's access, but also grants them the ability > to grant access to others. I haven't thought about this at all. I'm not a security expert, but wouldn't 'passable access/authentication' be opening up a pandora's box? You'll never know who has access to your system. I think another thing to consider is whether or not a mere user can grant access. Perhaps only the system administrator should be allowed to do this. This is the opposite extreme of Jarl's proposal. Thoughts? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Tue Apr 4 18:06:31 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Choice of ORB implementations Message-ID: <200004042209.SAA68050@archa12.cc.uga.edu> Jeff wrote: > What is omniORB written in then? C++? Yup. Apparently (from searching the archives) the gnome people were interested in using omniORB when they were looking for an ORB implementation, but the omniORB developers were mostly interested in developing a high quality C++ ORB (although that has sinced changed since they now have python bindings :) >> 3. Naming service: It seems like using the naming service might be a >> good bet for maintaining a list of available VSH implmementations (I >> think Jeff has described this before as a kind of domain name service >> that maps vsh implementations to their names (ie. Jeff's computer)). > > And the actual nodes contained therein. We need a directory service of a > sort. Well, the problem I see with this is that only certain nodes may be available to certain clients, and I was thinking that you'd have to authenticate with a remote connection so that connection can know what nodes to make available to you (based on your login). This goes back to something I was talking about earlier about specific authentication of nodes. This is a lot different then the directory service you are talking about. I think that the trading service (not implemented in ORBit) is designed for allowing searching for objects based on the service types that they offer. Maybe something like this could be utilized for searching for a "public" set of nodes. > My big concern is licensing. But I guess both are GNU L/GPL, right? Yup, omniORB is L/GPL. > Did you decide on which orb to use? For now, we're starting with ORBit. Jarl already has his code based around this (although I had to make him give up using gnorba :-< ) and I figured that you would like it best (seeing how it is associated with Gnome :-). It will be fairly easy to switch around since the python bindings are standardized (you can run diff on the two clients--Fnorb and orbit-python--in vsh-corba to see how similar they are), so we'll see what happens. >> Does anyone see a workaround for the threading and binding problems I >> mention above? How can we reconcile this? Do we need, ugh, two >> ORB implementations? > > Definitely not. Well... we'll see how things go with ORBit. For now, I'm all with it, but I am very worried about the fact that it is not multithreaded and think that might hamper things later. Plus I really like omniORB and they have a smooth set of python bindings :-) Jarl found a page with patches to make ORBit multithreaded (http://goethe.ira.uka.de/~wilhelm i/corba/orbit-mt.html). These patches are for 0.5.0 (and orbit-python requires 0.5.1) but I am going to try to work with these as much as possible and give ORBit the best shot. It may end up surprising me and I too may fall under the spell of the greatness of gnome :-) Brad From chapmanb at arches.uga.edu Tue Apr 4 18:20:51 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] summary for web Message-ID: <200004042223.SAA55240@archa10.cc.uga.edu> Jeff wrote: > So that is your summary for the web? Well... it wasn't meant to be :-) That was just a discussion topic that led from my original summary, which Jarl correctly pointed out was waaaaay to vague in how communication between remote vsh implementations should occur. It seemed to me the plan is pretty controversial since it proposes that all remote communication occur through the definition layer (the middle scripting layer) and not at the level of node processing. It was based on my attempts (probably failed) to learn about methods for implementing distributed systems based on Jarl's suggestion that all remote note authentication should occur in the definition layer. The proposal is basically derived from some systems I read about where the corba/distributed layer was implemented separately from the layers that do the actual work (the processing layer in our case). I tried to adapt it to the vsh setup. In addition, since this system would probably require a multithreaded server in the definition layer (to deal with possibly simultaneous communication with the processing layer and multiple remote implementations), this proposal led me to worry about using ORBit for all our communication. But if no one wants to voice any objects to the plan (and Jarl even said it was worth trying out :) that I guess it might as well be the basis of part of the summary for the web :-) Brad From chapmanb at arches.uga.edu Tue Apr 4 18:32:32 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Access levels in VSH Message-ID: <200004042235.SAA63922@archa10.cc.uga.edu> > jarl van katwijk wrote: >> >> We needed those to authorize DL's to login. Now this is where my problem >> begins: who should be able to grant others access? >> >> So we need some form of access level in the vsh system, how do we >> organize them? I copied a 'root' system like unix uses, so only the 1th DL >> can authorize others. But maybe we do need a more sophisticated system, >> something that not only allows DL's access, but also grants them the > ability >> to grant access to others. Jeff wrote: > I haven't thought about this at all. I'm not a security expert, but wouldn't > 'passable access/authentication' be opening up a pandora's box? You'll never > know who has access to your system. > > I think another thing to consider is whether or not a mere user can grant > access. Perhaps only the system administrator should be allowed to do this. > This is the opposite extreme of Jarl's proposal. Thoughts? It seems like Jarl is proposing a system like they implement (I think) in the MySQL database (and I guess in many other situations as well). The initial user (whoever is the system admin or whatever) gets root access to the database, and can thus do whatever they want, including using any databases and tables they want and assigning new users. Now, when a new user get assigned, they can be assigned with permissions to use certain databases and permission (or not) to authorize new users. I dig this scheme :-) I think you both described another system as well, in which only the root user can authorize new access. I don't think we need something this strict since the first system I described can be this strict (if the system admin wants it). So to kind of bring these two ideas together for vsh, whoever sets up vsh has a 'root' login that they can use to start up a dl. They can then use this login to assign new logins to users, and can pick optional permissions, including restricting access to only certain nodes (or other data) and allowing or disallowing creation of new users. Now these users can create new users, but don't have the option of passing on the ability to create to these subsequent users (this prevents the Pandora's box problem Jeff mentioned). What do you all think? How would the implementation for this be? Difficult? Brad From chapmanb at arches.uga.edu Tue Apr 4 18:51:01 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Re: window sill Message-ID: <200004042253.SAA73000@archa10.cc.uga.edu> > You may have seen the 'window sill' mentioned on the Loci list. This is > pretty much a status bar for the windowlets that appear in the workspace. > Attached is a screenshot of one prototype window sill. I dig the window sill idea! Although I have no buisness saying anything about GUI design, I'll make a few comments below :-) > INFO > * Visible only when window is shaded > * Button contains a text message for each info item (not context-sensitive > help) > * Time elapsed while unprocessed > * Unprocessed/processing/processed > * Location > * Help message for window's node (truncated) Will the info button be replacing the "help" window thingy that I started using, or in addition to that? > OCCUPY/UNOCCUPY > * Click button1 to make self window pane occupy parent window > * Click button3 to unoccupy self window pane from parent window > * Window sill also occupies parent's > > (When I say 'parent', I mean a node that contains a network of nodes, one of > which being the node in question.) This is a really cool idea, but will the old windowlet with the network GUI get recycled by python memory collection if it gets popped out of a parent window? Just throwing that out, I really have no idea how memory collection works in pyGtk. Maybe it will still be fine as long as you maintain a reference to it. Also, I was having a lot of problems getting windows to refresh properly after resetting the contents of a windowlet... > VIEW > * Click button1 or button3 to cycle through views: > * GUI view: Gtk (composite) interface Can you describe this view? What does it look like? > * Network normal: Network with icons, links and windows Is this the view we currently have? > * Network world: Only links shown but for entire network (no scrolling > needed). Single-click in workspace switches view back to network > normal, focused in area of workspace where clicked (like a zoom > feature) Jeff, I was trying to play around with the canvas zoom feature as soon as I saw it was a feature, because I thought it would be a really cool thing to use. The GUI ended up really ugly for me because not everything scaled in the same way, especially the text box, if I remember correctly. > * Info view (all messages in single view): > * Time elapsed while unprocessed > * Unprocessed/processing/processed > * Location > * Help message for window's node > * (others) > * Context-sensitive help message: for ONE selected node in window's > workspace, not for the window's node How are the old views "stored"? For instance, if you have the view we have now, with links and windows and all that, will the view be exactly the same (ie. all the loci in the same places, all of the same windows open, etc) when you scroll back around to it? And again, I'm not positive if you'll see the refresh problem I couldn't fix. Just playing devil's advocate on all this stuff. The ideas are really cool, and I look forward to seeing them in action :-) Brad From jarl at casema.net Wed Apr 5 01:47:01 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004011726.MAA61350@archa11.cc.uga.edu> <38EA24FE.5E88B45F@geoserve.net> Message-ID: <38EAD355.AB7C46B6@casema.net> > > > Are there considerations we should be taking into account? > > My big concern is licensing. But I guess both are GNU L/GPL, right? ORbit is GPL, not sure if's L/GPL or just plain, does this matter? > > mention above? How can we reconcile this? Do we need, ugh, two > > ORB implementations? > > Definitely not. Hehe.. Brad & I are giving ORbit a try. The gnorba\goad stuff has to be out for a while until Python has binding for it. > > > Being partial to Gnome, and considering how much Gnome/Gtk is being used > already, I'd prefer ORBit. I'm in favoir for as much GNOME intergration as possible, but some faccets wont be done right now, but once they are useable. From jarl at casema.net Wed Apr 5 01:52:13 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Access levels in VSH References: <200004020116.UAA147228@archa12.cc.uga.edu> <38E8F0D8.BEAB23ED@casema.net> <38EA2D0C.810E8BE7@geoserve.net> Message-ID: <38EAD48D.D3591A80@casema.net> > > > > We needed those to authorize DL's to login. Now this is where my problem > > begins: who should be able to grant others access? > > > > So we need some form of access level in the vsh system, how do we > > organize them? I copied a 'root' system like unix uses, so only the 1th DL > > can authorize others. But maybe we do need a more sophisticated system, > > something that not only allows DL's access, but also grants them the ability > > to grant access to others. > > I haven't thought about this at all. I'm not a security expert, but wouldn't > 'passable access/authentication' be opening up a pandora's box? You'll never > know who has access to your system. > > I think another thing to consider is whether or not a mere user can grant > access. Perhaps only the system administrator should be allowed to do this. > This is the opposite extreme of Jarl's proposal. Thoughts? > This is how the BL has security currently implemented :) The very first DL can login without a password, and will become the only one being able to grant others access. I'll leave it this way for now, but it aint the final system yet I'm afraid. bye, jarl From jarl at casema.net Wed Apr 5 01:58:01 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004042209.SAA68050@archa12.cc.uga.edu> Message-ID: <38EAD5E9.A274AA4E@casema.net> > I think that the trading service (not implemented in ORBit) is > designed for allowing searching for objects based on the service types > that they offer. Maybe something like this could be utilized for > searching for a "public" set of nodes. Check out goad people, http://developer.gnome.org/doc/API/libgnorba/gnorba-goad.html but again: we'' have to wait for the python bindings :( > For now, we're starting with ORBit. Jarl already has his code based > requires 0.5.1) but I am going to try to work with these as much as > possible and give ORBit the best shot. It may end up surprising me and > I too may fall under the spell of the greatness of gnome :-) > Hehe, you will! From bizzaro at geoserve.net Wed Apr 5 10:19:53 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004042209.SAA68050@archa12.cc.uga.edu> Message-ID: <38EB4B89.D12E7B40@geoserve.net> Brad Chapman wrote: > > Well, the problem I see with this is that only certain nodes may > be available to certain clients, and I was thinking that you'd have > to authenticate with a remote connection so that connection can know > what nodes to make available to you (based on your login). This goes > back to something I was talking about earlier about specific > authentication of nodes. This is a lot different then the directory > service you are talking about. Again, this is something like what Unix already has: permission, user and group settings for individual files and directories. Can we not make use of what is already present in Unix? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 10:24:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:42 2006 Subject: [Pipet Devel] summary for web References: <200004042223.SAA55240@archa10.cc.uga.edu> Message-ID: <38EB4C9F.A71455F5@geoserve.net> Brad Chapman wrote: > > It seemed to me the plan is pretty controversial since it proposes > that all remote communication occur through the definition layer (the > middle scripting layer) and not at the level of node processing. It > was based on my attempts (probably failed) to learn about methods > for implementing distributed systems based on Jarl's suggestion that > all remote note authentication should occur in the definition layer. > The proposal is basically derived from some systems I read about where > the corba/distributed layer was implemented separately from the layers > that do the actual work (the processing layer in our case). I tried to > adapt it to the vsh setup. I thought communication (between cores) would occur in the brokering layer. This is what GMS was going to handle, right? If communication occurs through the Python-based definitions layer, what is the broker layer used for? It must be used for more than communicating with Overflow (processing layer). > In addition, since this system would probably require a > multithreaded server in the definition layer (to deal with possibly > simultaneous communication with the processing layer and multiple > remote implementations), this proposal led me to worry about using > ORBit for all our communication. As an aside, we will eventually need a multithreaded connection between the DL and the front ends. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 10:27:14 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Access levels in VSH References: <200004042235.SAA63922@archa10.cc.uga.edu> Message-ID: <38EB4D42.2D153225@geoserve.net> Brad Chapman wrote: > > So to kind of bring these two ideas together for vsh, whoever sets > up vsh has a 'root' login that they can use to start up a dl. They can > then use this login to assign new logins to users, and can pick > optional permissions, including restricting access to only certain > nodes (or other data) and allowing or disallowing creation of new > users. Now these users can create new users, but don't have the option > of passing on the ability to create to these subsequent users (this > prevents the Pandora's box problem Jeff mentioned). > What do you all think? How would the implementation for this be? > Difficult? Complex. We can probably start with a simpler method for authentication and worry about this later. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at ARCHES.UGA.EDU Wed Apr 5 10:33:52 2000 From: chapmanb at ARCHES.UGA.EDU (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Choice of ORB implementations In-Reply-To: <38EB4B89.D12E7B40@geoserve.net> Message-ID: > Brad Chapman wrote: > > > > Well, the problem I see with this is that only certain nodes may > > be available to certain clients, and I was thinking that you'd have > > to authenticate with a remote connection so that connection can know > > what nodes to make available to you (based on your login). This goes > > back to something I was talking about earlier about specific > > authentication of nodes. This is a lot different then the directory > > service you are talking about. J.W. Bizzaro wrote: > Again, this is something like what Unix already has: permission, user and > group settings for individual files and directories. Can we not make use of > what is already present in Unix? I'm confused about how you want to make use of the unix permission system in a distributed system. I guess you mean that we should be writing our own specific type directory service. I'm opposed to this (at the present time) for two reasons: 1. I think it will be a pain in the arse to write this, and will take a lot of time and knowledge. 2. I would like to stick with open standards. It seems like we have went out of our way to do this thus far by using XML and CORBA. If we start using our own "proprietary" setup, then we jepordize the interoperability of our system. Or do you have a specific CORBA service in mind that we could use? Brad From chapmanb at arches.uga.edu Wed Apr 5 10:45:55 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] summary for web In-Reply-To: <38EB4C9F.A71455F5@geoserve.net> Message-ID: [...snip...my one paragraph summary of my idea...] Jeff wrote: > I thought communication (between cores) would occur in the brokering layer. > This is what GMS was going to handle, right? If communication occurs through > the Python-based definitions layer, what is the broker layer used for? It > must be used for more than communicating with Overflow (processing layer). Well, this is why I thought my plan was controversial, and not a simple summary :-) Although Jarl can probably answer this better, I think that the brokering layers primary responsibility will be efficient execution of nodes. This is what Jarl was proposing with his (really cool) neural net and genetic algorithms ideas. I think this will be really important since once you get complicated programs with long run times and intricate work flow diagrams, an important (and interesting!) question will be how to most efficiently execute the programs. The idea is that the genetic algorithms can learn from "good" setups and help users design setups--and I think this could eventually be integrated into your ideas of making Loci (now vsh) a development environment. So, my idea was that by having remote node communication occur in the definition layer, we could free up the brokering layer to do this kind of stuff. I think this will speed up processing times and make for a more efficient overall system (I had some arguments for these points in my first mail about this). Does this seem like an unreasonable proposal? Jeff wrote: > As an aside, we will eventually need a multithreaded connection between the DL > and the front ends. Well, this is another reason why I'm worried about using ORBit for everything. Not having any experience with designing multi-threaded corba applications, I really can't predict the kinds of problems we might see, or how well ORBit will handle multithreading on the level that will probably be going on in the definition layer. I guess this is an issue where we'll just have to try it and see :-) Brad From jarl at casema.net Wed Apr 5 09:47:11 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] summary for web References: <200004042223.SAA55240@archa10.cc.uga.edu> <38EB4C9F.A71455F5@geoserve.net> Message-ID: <38EB43DF.82B1048C@casema.net> "J.W. Bizzaro" wrote: > Brad Chapman wrote: > > > > It seemed to me the plan is pretty controversial since it proposes > > that all remote communication occur through the definition layer (the > > middle scripting layer) and not at the level of node processing. It > > was based on my attempts (probably failed) to learn about methods > > for implementing distributed systems based on Jarl's suggestion that > > all remote note authentication should occur in the definition layer. > > The proposal is basically derived from some systems I read about where > > the corba/distributed layer was implemented separately from the layers > > that do the actual work (the processing layer in our case). I tried to > > adapt it to the vsh setup. > > I thought communication (between cores) would occur in the brokering layer. > This is what GMS was going to handle, right? If communication occurs through > the Python-based definitions layer, what is the broker layer used for? It > must be used for more than communicating with Overflow (processing layer). Like the name already suggest: brokering layer, so the comm. between instances will be handled by the BL (gms). I dont know what is Brad want to build, but it seem to have something to do with DL specific stuff. From bizzaro at geoserve.net Wed Apr 5 10:56:14 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: window sill References: <200004042253.SAA73000@archa10.cc.uga.edu> Message-ID: <38EB540E.457D71A@geoserve.net> Brad Chapman wrote: > > Will the info button be replacing the "help" window thingy that I > started using, or in addition to that? I want to define 2 types of 'help': One is a message about the particular node. The other, since a node can be made up of a network of nodes, is a message about the node SELECTED WITHIN the window of the node. This I would call 'context-sensitive help', since it will change according to the context. The Info button will contain only the first type of 'help' (for now). And the message will have to be truncated, since the Info button can be only so large. > > (When I say 'parent', I mean a node that contains a network of > > nodes, one of which being the node in question.) > > This is a really cool idea, but will the old windowlet with the > network GUI get recycled by python memory collection if it gets popped > out of a parent window? Just throwing that out, I really have no idea > how memory collection works in pyGtk. Maybe it will still be fine as > long as you maintain a reference to it. The Gtk object, that is the 'view' in the window, will not be thrown out. I can just use 'show' and 'hide'. > Also, I was having a lot of problems getting windows to refresh > properly after resetting the contents of a windowlet... Just now or a while ago? You mentioned this a couple months ago. > > * Click button1 or button3 to cycle through views: > > * GUI view: Gtk (composite) interface > > Can you describe this view? What does it look like? This is the composite GUI I keep yammering about. It contains Gtk widgets arranged according to the heirarchy of the network (if there is one) contained in the node. > > * Network normal: Network with icons, links and windows > > Is this the view we currently have? Yep. > Jeff, I was trying to play around with the canvas zoom feature as soon > as I saw it was a feature, because I thought it would be a really cool > thing to use. The GUI ended up really ugly for me because not > everything scaled in the same way, especially the text box, if I > remember correctly. I don't understand. You just tried to code this feature? What is the 'text box'? > How are the old views "stored"? For instance, if you have the view we > have now, with links and windows and all that, will the view be > exactly the same (ie. all the loci in the same places, all of the same > windows open, etc) when you scroll back around to it? As long as VSh (or the Gnome front) remains running, this information will not go away. The problem is when the program is shut down and restarted. If the user wants to reload a network, the middleware may have linkage information stored, but the front end will not have x/y positions stored...at least not now. We do need to come up with a way to store this user interface information. I most certainly don't want to MIX user interface information with the information the core needs, but we can keep it along side or parallel to the core information...perhaps as separate files. > And again, I'm not positive if you'll see the refresh problem I > couldn't fix. I haven't come across the problem, but I have heard mention of it on the Gnome lists. Apparently, we can force a refresh of the widgets. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 11:14:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Choice of ORB implementations References: Message-ID: <38EB5850.B3B83A02@geoserve.net> Brad Chapman wrote: > > I'm confused about how you want to make use of the unix permission system > in a distributed system. > I guess you mean that we should be writing our own specific type directory > service. I'm opposed to this (at the present time) for two reasons: Oh, I wasn't even considering directory services when I mentioned that. It was just a simple suggestion to use the permissions, etc. that are already set in the Unix filesystem. But of course, we don't even agree on how nodes should be stored and used. My suggestion of making use of the Unix filesystem stems from my idea that the system should work from within that permanent storage medium. Your (and Jarl's) approach is to work from an ephemeral, CORBA-based medium. I'm not saying 'don't use CORBA'. I'm saying that the storage medium should always reflect what is happening in the working medium (CORBA). This is first of all important in case there is a catastrophic failure. And I think the working medium can glean information from the storage medium, such as who owns a file and who can use it. > 2. I would like to stick with open standards. It seems like we have went > out of our way to do this thus far by using XML and CORBA. If we start > using our own "proprietary" setup, then we jepordize the interoperability > of our system. I'm not suddenly against open standards. The Unix filesystem is in fact an older standard than most others :-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Wed Apr 5 11:16:43 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: window sill In-Reply-To: <38EB540E.457D71A@geoserve.net> Message-ID: Brad wrote: > > Will the info button be replacing the "help" window thingy that I > > started using, or in addition to that? Jeff wrote: > I want to define 2 types of 'help': One is a message about the particular > node. The other, since a node can be made up of a network of nodes, is a > message about the node SELECTED WITHIN the window of the node. This I would > call 'context-sensitive help', since it will change according to the context. > > The Info button will contain only the first type of 'help' (for now). And the > message will have to be truncated, since the Info button can be only so large. That sounds very snazzy :-) > > > (When I say 'parent', I mean a node that contains a network of > > > nodes, one of which being the node in question.) > > > > This is a really cool idea, but will the old windowlet with the > > network GUI get recycled by python memory collection if it gets popped > > out of a parent window? Just throwing that out, I really have no idea > > how memory collection works in pyGtk. Maybe it will still be fine as > > long as you maintain a reference to it. > > The Gtk object, that is the 'view' in the window, will not be thrown out. I > can just use 'show' and 'hide'. Okay... I just thought you would have to remove a child window before you could insert another one in the windowlet. I thought you would get one of those wonderful gnome error messages about the parent node already having a child (since they can't have more than one, can they?). But then again, I might be smoking crack... > > Also, I was having a lot of problems getting windows to refresh > > properly after resetting the contents of a windowlet... > > Just now or a while ago? You mentioned this a couple months ago. Then, now, still, whenever. I never fixed it, I just had a stupid workaround by closing the window when I changed the windowlet, so they the user would have to open it back up and it would refresh automatically :-) Of course, this cheap hack won't work for your ideas. If you can make stuff refresh I would be so happy to learn how, because I tried calling all kinds of different refresh calls and couldn't get any of them to do anything for it. If you want to try it out, maybe you could try and make the main Loci window refresh after selecting a file (while it is waiting for the file info to come back from the definition layer). Right now it sits in a really ugly state (looking like it is locked up), and I couldn't seem to get a refresh to fix this, so I just had to give up before I spent my whole life on it. I am stuck :-< > > Can you describe this view? What does it look like? > > This is the composite GUI I keep yammering about. It contains Gtk widgets > arranged according to the heirarchy of the network (if there is one) contained > in the node. Is this what you are proposing will replace the GtkCTree view? Will be have to code our own widget for this? [...snip... my poor description of zoom...] > > I don't understand. You just tried to code this feature? What is the 'text > box'? I did code this feature, and then killed it because it sucked :-< There is a zoom command for the canvas which is supposed to provide "automatic" zooming, but I couldn't make it work. By the text box, I mean the little text thingy with the name of the widget (under the widget shape and little people picture :). > As long as VSh (or the Gnome front) remains running, this information will not > go away. The problem is when the program is shut down and restarted. If the > user wants to reload a network, the middleware may have linkage information > stored, but the front end will not have x/y positions stored...at least not > now. > > We do need to come up with a way to store this user interface information. I > most certainly don't want to MIX user interface information with the > information the core needs, but we can keep it along side or parallel to the > core information...perhaps as separate files. I see... I guess this is something that will have to come later on. Let me just stick with remembering one thing (the links) at a time :-) Brad From bizzaro at geoserve.net Wed Apr 5 11:18:19 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] summary for web References: Message-ID: <38EB593B.2531C4E7@geoserve.net> Brad Chapman wrote: > > So, my idea was that by having remote node communication occur in > the definition layer, we could free up the brokering layer to do this kind > of stuff. I think this will speed up processing times and make for a more > efficient overall system (I had some arguments for these points in my > first mail about this). > Does this seem like an unreasonable proposal? Then the DL really does 2 things: (1) communicates between front and BL, and (2) communicates between different instances of BLs across the Internet. Correct? Should the DL be split into 2 parts then? > Well, this is another reason why I'm worried about using ORBit for > everything. Not having any experience with designing multi-threaded corba > applications, I really can't predict the kinds of problems we might see, > or how well ORBit will handle multithreading on the level that will > probably be going on in the definition layer. I guess this is an issue > where we'll just have to try it and see :-) Better support for multithreading is something the ORBit developers are working on? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 11:34:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: window sill References: Message-ID: <38EB5CFA.CA5C117B@geoserve.net> Brad Chapman wrote: > > Okay... I just thought you would have to remove a child window before you > could insert another one in the windowlet. I thought you would get one of > those wonderful gnome error messages about the parent node already having > a child (since they can't have more than one, can they?). But then again, > I might be smoking crack... It depends on the container. I need to find one that will let me flip between overlapping children. The fixed-position and notebook containers come to mind. > Then, now, still, whenever. I never fixed it, I just had a stupid > workaround by closing the window when I changed the windowlet, so they the > user would have to open it back up and it would refresh automatically :-) > Of course, this cheap hack won't work for your ideas. If you can make > stuff refresh I would be so happy to learn how, because I tried calling > all kinds of different refresh calls and couldn't get any of them to do > anything for it. If you want to try it out, maybe you could try and make > the main Loci window refresh after selecting a file (while it is waiting > for the file info to come back from the definition layer). Right now it > sits in a really ugly state (looking like it is locked up), and I couldn't > seem to get a refresh to fix this, so I just had to give up before I spent > my whole life on it. I am stuck :-< Did you try a Gtk refresh or a canvas refresh? > > This is the composite GUI I keep yammering about. It contains Gtk widgets > > arranged according to the heirarchy of the network (if there is one) contained > > in the node. > > Is this what you are proposing will replace the GtkCTree view? Will be > have to code our own widget for this? No, I was suggesting to you that the 'view we have now' (the workspace normal view) replace the GtkCTree view for taking listings of directories. The composite GUI will look like a regular Gtk interface. > > I don't understand. You just tried to code this feature? What is the 'text > > box'? > > I did code this feature, and then killed it because it sucked :-< There is > a zoom command for the canvas which is supposed to provide "automatic" > zooming, but I couldn't make it work. Really? Is the code still in there? > By the text box, I mean the little > text thingy with the name of the widget (under the widget shape and little > people picture :). I'd probably remove icons and text boxes in the zoom view. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 11:37:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: [Pipet Devel] Re: window sill References: Message-ID: <38EB5DC2.C9F75603@geoserve.net> Brad wrote: > Will the info button be replacing the "help" window thingy that I > started using, or in addition to that? The help messages are exactly what you started but implemented differently. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 13:10:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] summary for web References: <200004042223.SAA55240@archa10.cc.uga.edu> <38EB4C9F.A71455F5@geoserve.net> <38EB43DF.82B1048C@casema.net> Message-ID: <38EB7380.7793CF17@geoserve.net> Jarl van Katwijk wrote: > > Like the name already suggest: brokering layer, so the comm. between instances > will be handled by the BL (gms). > > I dont know what is Brad want to build, but it seem to have something to do with > DL specific stuff. Hmmm. Well, Brad says here that it is your idea to have the DL manage authentication between instances: Brad wrote: > was based on my attempts (probably failed) to learn about methods > for implementing distributed systems based on Jarl's suggestion that > all remote note authentication should occur in the definition layer. Shouldn't the layer that manages authentication also manage communication? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 5 13:52:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <38EB5850.B3B83A02@geoserve.net> Message-ID: <38EB7D58.847D02A4@geoserve.net> "J.W. Bizzaro" wrote: > > I'm not saying 'don't use CORBA'. I'm saying that the storage medium should > always reflect what is happening in the working medium (CORBA). This is first > of all important in case there is a catastrophic failure. And I think the > working medium can glean information from the storage medium, such as who owns > a file and who can use it. It's just a suggestion. If you really have a way to make a distributed pseudo-filesystem, I'd like to hear more about it and get some opinions from the others. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Wed Apr 5 13:09:14 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] summary for web References: <200004042223.SAA55240@archa10.cc.uga.edu> <38EB4C9F.A71455F5@geoserve.net> <38EB43DF.82B1048C@casema.net> <38EB7380.7793CF17@geoserve.net> Message-ID: <38EB733A.6D6DE478@casema.net> > > Hmmm. Well, Brad says here that it is your idea to have the DL manage > authentication between instances: > > Brad wrote: > > was based on my attempts (probably failed) to learn about methods > > for implementing distributed systems based on Jarl's suggestion that > > all remote note authentication should occur in the definition layer. > > Shouldn't the layer that manages authentication also manage communication? Yes. But about 'my suggestion', I think we got a misunderstanding here, Brad and I have had some discussion about this, and I talked about a bl->dl corba interface, (we currently are doing the dl->bl). Seems I have to read Brads mail better: he was talking about : "a. All authentication between remote vsh implementations occurs in one layer, the definition layer (this is the point that Jarl made)." This should not be the case. Otherwise there's no point in DL's loggin into the BL. BUT: brad's concern about the lost of speed due to stalling during network communication is someting to think about, but surtainly wont be a big problem when we'll use the right network libraries. Brad: maybe this is worth another irc session? :) If you want to code this network stuff, be my guest, it doesn't exsist at all yet.. bye, jarl From jarl at casema.net Wed Apr 5 13:19:14 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <38EB5850.B3B83A02@geoserve.net> <38EB7D58.847D02A4@geoserve.net> Message-ID: <38EB7592.B568E88A@casema.net> > It's just a suggestion. If you really have a way to make a distributed > pseudo-filesystem, I'd like to hear more about it and get some opinions from > the others. > We're building a graphical distributed dataflow system, so how hard can a DFS be 8) From chapmanb at arches.uga.edu Thu Apr 6 09:52:33 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Security model Message-ID: <200004061355.JAA110988@archa10.cc.uga.edu> This is a forward of a message from Jarl. > Hi, > > I've been thinking a lot about how we'll do the > security model, > it's complicated stuff :) > > What do you think about this : > > 1a- BL's authenticate DL's for applying XML into > the processing engine. > 1b- The 1st DL loggin into the BL is automatically > the 'root' DL, > and has the ability to grant other DL's > access. > 1c- Other DL's (local and remote) can connect via > CORBA after > the root DL has granted them access. > 1d- DL's can connect to multiple BL's. > 1e- BL nodes (or: VSH subnets) can communicate > with other BL nodes > only if both nodes have the same parent > DL. > > 2a- a DL authenticates other DL's for access to > its nodes\subnets. > 2b- DL's can connect to other DL's and > upload\download XML > documents outof and into. > 2c- No DL can connect to the root DL, so no > non-root DL has ability 2a. > > thoughts? > > bye, > jarl From chapmanb at arches.uga.edu Thu Apr 6 09:52:54 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: Security model Message-ID: <200004061355.JAA112514@archa10.cc.uga.edu> Hi Jarl; > I've been thinking a lot about how we'll do the > security model, > it's complicated stuff :) I know :-) > What do you think about this : I like it! I think this is a really good model to start with. I'm just going to kind of talk myself through what needs to be done to make it happen. > 1a- BL's authenticate DL's for applying XML into > the processing engine. Okay, we have this setup with the dl->bl idl. > 1b- The 1st DL loggin into the BL is automatically > the 'root' DL, > and has the ability to grant other DL's > access. This will work through your authorize function. > 1c- Other DL's (local and remote) can connect via > CORBA after > the root DL has granted them access. This "connection" will be mediated by the local DL, right? So a remote DL will never directly communicate with a local BL. The local DL will accept some XML to be processed from the remote DL, and then submit this to the local BL under its own dlId and uri instanceID. So this DL authentication (to gain access to nodes) will need to mediated through a dl->dl connection that I'll need to do. > 1d- DL's can connect to multiple BL's. Okay. This will be through the mechanism we already have for 1a. > 1e- BL nodes (or: VSH subnets) can communicate > with other BL nodes > only if both nodes have the same parent > DL. Makes sense for bl security. This will be something that'll need to go into the bl code. > 2a- a DL authenticates other DL's for access to > its nodes\subnets. Right, this is what I mentioned in 1c, and is something I'll have to do. > 2b- DL's can connect to other DL's and > upload\download XML > documents outof and into. This is again the dl->dl idl that I'll need to work out (same idl as 1c,2a). > 2c- No DL can connect to the root DL, so no > non-root DL has ability 2a. This makes a lot of sense for security reasons. This way, no one can remotely get access to a root DL. So before the local DL starts allowing remote DLs access, the local root DL will have to create a new DL to allow this access. Am I reading you right on this one? > thoughts? How will the permissions for node access by assigned? All authorized DLs (by tha authorize function) have access to the same nodes as their parent (the DL that created them)? If we want to restrict access to only certain nodes for local DLs, then we will need a more complicated authorization scheme. I'm not sure if we really need this kind of fine scale authorization, and would rather leave it out, but it is up to you :-) Thanks for putting things together so concisely! I'm going to forward these two messages to the vsh list so other people can look at the scheme. Talk to you soon. Brad From jarl at casema.net Thu Apr 6 16:15:40 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> Message-ID: <38ECF06C.F84BA7B9@casema.net> > > 1c- Other DL's (local and remote) can connect via > > CORBA after > > the root DL has granted them access. > > This "connection" will be mediated by the local DL, right? So a remote > DL will never directly communicate with a local BL. The local DL will > accept some XML to be processed from the remote DL, and then submit > this to the local BL under its own dlId and uri instanceID. So this > DL authentication (to gain access to nodes) will need to mediated > through a dl->dl connection that I'll need to do. No, I'm saying the BL wont notice the differance between a local or a remote DL. The only problem with remote DL's is that the (local) root DL must know about that remote one in order to authoritized it. But these are only techinical implementation problems, they hardly count compared to this security model :-) > > 1e- BL nodes (or: VSH subnets) can communicate > > with other BL nodes > > only if both nodes have the same parent > > DL. > > Makes sense for bl security. This will be something that'll need to go > into the bl code. They do. But the point is that the brokering layer will get inter local transport system: local subnet-> remote subnet. It's no big deal, but everybody should know that this going on. (note: the transported data will be encrypted with the DL password as key.) > > 2a- a DL authenticates other DL's for access to > > its nodes\subnets. > > Right, this is what I mentioned in 1c, and is something I'll have to > do. OK, so this means will will have a system that is like the unix user\group system, only groups have passwords too in VSH! group ~~ BL level (DL id & DL password give access to whole set of subnets and nodes that are childs of that DL) user ~~ DL level (??? id & ??? password give access to subset of the subnets and nodes that are childs of that DL) This is just to illustrate the system, dont take it too strict. > > > 2c- No DL can connect to the root DL, so no > > non-root DL has ability 2a. > > This makes a lot of sense for security reasons. This way, no one can > remotely get access to a root DL. So before the local DL starts > allowing remote DLs access, the local root DL will have to create a > new DL to allow this access. Am I reading you right on this one? > Yeppo! The root DL will only be there to grant others access and do some very-very-very basic subnet processing. The most work will spawn out of other DL's. > > How will the permissions for node access by assigned? All > authorized DLs (by tha authorize function) have access to the same > nodes as their parent (the DL that created them)? No, they have access to the nodes created with THEIR DLid. And yes, this makes it possible to have multiple logins on the same DLid. To get access to another DL's nodes, use login 'level' (?) 2. We should therefor deside if it can be possible for a DL to login to another DL and to a BL at the same time. I didn't though about the consequences yet.. > If we want to restrict access to only certain nodes for local DLs, > then we will need a more complicated authorization scheme. I'm not > sure if we really need this kind of fine scale authorization, and > would rather leave it out, but it is up to you :-) Maybe this new field of the uriS will make this possible? so it will be like this (simplyfied): struct uriS { long instaceID; long groupID; //aint the same as the unix 'group' !! long subnetID; long nodeID; }; Giving any lead? From chapmanb at arches.uga.edu Fri Apr 7 06:39:52 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: Security model Message-ID: <200004071042.GAA173090@archa11.cc.uga.edu> >> This "connection" will be mediated by the local DL, right? So a remote >> DL will never directly communicate with a local BL. The local DL will >> accept some XML to be processed from the remote DL, and then submit >> this to the local BL under its own dlId and uri instanceID. So this >> DL authentication (to gain access to nodes) will need to mediated >> through a dl->dl connection that I'll need to do. > > No, I'm saying the BL wont notice the differance between a local or a remote > DL. > > The only problem with remote DL's is that the (local) root DL must know about > that remote one in order to authoritized it. Okay, I think we are saying the same thing--that a local dl has to accept a connection from a remote dl and get it authorized to use the local bl. This will be occuring in a (not yet defined) dl->dl corba connection. > (note: the transported data will be encrypted with the DL password as key.) Man, Jarl, you are awesome! This just helped me figure out a problem I was having with secure password storage in the dl. Thanks! > OK, so this means will will have a system that is like the unix user\group > system, > only groups have passwords too in VSH! This sounds like a good plan to me. Jeff, does this jive with your security ideas? >> How will the permissions for node access by assigned? All >> authorized DLs (by tha authorize function) have access to the same >> nodes as their parent (the DL that created them)? > > No, they have access to the nodes created with THEIR DLid. > And yes, this makes it possible to have multiple logins on the same DLid. > To get access to another DL's nodes, use login 'level' (?) Okay, I think I understand your point, although I'm not sure what you mean by login level... > We should therefor deside if it can be possible for a DL to login to another > DL and to a BL at the same time. I didn't though about the consequences yet.. This makes my head hurt :-) I think we should keep it simple for the time being. I think the only idea about of one dl being able to log into another was so one dl could control the other (ie. you could control the gnome gui display using the (not yet developed) speech recognition user interface. Am I right on this Jeff, or did you have bigger ideas of two dls connecting? > Maybe this new field of the uriS will make this possible? > so it will be like this (simplyfied): > struct uriS { > long instaceID; > long groupID; //aint the same as the unix 'group' !! > long subnetID; > long nodeID; > }; > > Giving any lead? Okay, so a group is "smaller" than a instanceID, and groups subnets and nodes and not users. Am I following you correctly? Brad From chapmanb at arches.uga.edu Fri Apr 7 07:04:54 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Choice of ORB implementations Message-ID: <200004071107.HAA53566@archa10.cc.uga.edu> Jeff wrote: >> >> I'm not saying 'don't use CORBA'. I'm saying that the storage medium >> should always reflect what is happening in the working medium (CORBA). >> This is first of all important in case there is a catastrophic failure. >> And I think the working medium can glean information from the storage medium, >> such as who owns a file and who can use it. > I definately agree that the permanent storage should reflect what is happening on the CORBA level. However, I don't really think that managing it via the unix filesystem is the easiest way, since this seems to imply that every remote user who connects will have to be associated with a group on the local filesystem, so that vsh can determine what nodes are available. We definately need to work out how this should work, but I'm still gunning for having stored loci have a tag that reflects their group, and then have another storage file that associates remote logins with groups. This is analagous to the unix filesystem, but doesn't use it, because I feel like then the vsh user will have to configure their local filesystem outside of a running vsh implementation, while the other way will allow this configuration within a vsh (as an extension of your development environment idea). We could also tie the vsh development environment with assigning groups in the local filesystem, but it seems like we are abusing the meanings of groups to make them extend to remote users. Isn't all the unix group and permission stuff meant for configuring a local environment, and not a remote one? I think we have a lot of common ground on how things should work, we just need to work out the implementation of those things :-) > It's just a suggestion. If you really have a way to make a distributed > pseudo-filesystem, I'd like to hear more about it and get some opinions from > the others. I've been reading into this more. I don't think the naming service will work for a distributed pseudo-filesystem. Although it is organized in a tree-like structure like the filesystem, it is meant for publishing corba objects. Each subnet or node that is available on a computer will not be a different corba object, but rather will be represented as XML, so we can't publish these objects in a naming service (or any other service for that matter). This is why I think the way things should work is that the naming service is used to locate remote hosts (like dns) and then you should query them to see the full list of nodes that are available. In addition to this, we could also utilize the trading service, which publishes objects by description (rather than by name). So a vsh instance could publish their connection object, and then associate the description of the object with the publically available nodes (along with other information about the computer such as processing power, etc.). Then a user could search for a particular subnet or node (a particular program) and find out where it is available. So, stealing some analogies from the corba documentation, our naming service would be like the white pages, where you can find other computers by their known name, and the trading service would be like the yellow pages, where you can look up the computers by the services they offer. I know this isn't your vision for how things should work, but seems to implement the same ideas, only using already designed corba services. Does anyone have any suggestions/comments/criticisms? Brad From chapmanb at arches.uga.edu Fri Apr 7 07:16:20 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] summary for web Message-ID: <200004071118.HAA158284@archa11.cc.uga.edu> Jeff wrote: > Then the DL really does 2 things: (1) communicates between front and BL, and > (2) communicates between different instances of BLs across the Internet. > Correct? > > Should the DL be split into 2 parts then? What do you mean by this? My plan was that the dl should be split into two parts programmatically (ie. two different servers with APIs). I think the two different objects will need to interoperate quite a bit, and haven't though about separating them formally with corba or something. > Better support for multithreading is something the ORBit developers are > working on? You're asking me about gnome development? :-) I looked through the gnome-devel archives and didn't seem much mention of orbit development (there is an orbit list but I couldn't find an archive for it). From my rough estimation, it seems like orbit isn't under continual development by anyone, but is enhanced when a general need for enhancement arises in gnome. Threading issues are on the out of date (the developers' words, not mine) todo list in cvs, but I have no concept of when this might be addressed (probably as soon as someone wants it bad enough to hack on it). I don't see any mention of implementing a trading service, and I kind of doubt this is on many people's mind since I think this is what gnorba and bonobo are meant to do. But I'm just guessing at all this. If anyone knows better, I'd love to hear it. Brad From chapmanb at arches.uga.edu Fri Apr 7 07:33:20 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: window sill Message-ID: <200004071135.HAA121862@archa12.cc.uga.edu> [...snip... my description of parent and child widgets...] Jeff wrote: > It depends on the container. I need to find one that will let me flip > between > overlapping children. The fixed-position and notebook containers come to > mind. Damn, you are so smart! This is a really good idea that I never even thought of. [...snip... description of my refresh problem...] > Did you try a Gtk refresh or a canvas refresh? I believe I tried calling both types--I think I tried request_redraw on the canvas and queue_draw on the Widget. I don't really understand how all of the refreshing works tho. >> Is this what you are proposing will replace the GtkCTree view? Will be >> have to code our own widget for this? > > No, I was suggesting to you that the 'view we have now' (the workspace normal > view) replace the GtkCTree view for taking listings of directories. The > composite GUI will look like a regular Gtk interface. Okay...how can you then distinguish between moving a locus from one workspace to another via dnd, and copying a locus unto a new workspace via dnd (ie. if you are copying a saved locus onto to the workspace to use, or if you are dragging a directory out of a representation of a local filesystem)? Will the workspace need to keep track of what kind of information it is holding? Similary, a composite representing a save directory or local filesystem will need to react different to loci that are dragged into them then a "regular" workspace would. I guess we would probably need to define two different workspace types in the code. Also, how will a workspace be populated with gui representations of loci if you, for instance, open up a save container full of loci? Just stick them with equal spacing throughout the workspace, like opening a directory on a mac? >> I did code this feature, and then killed it because it sucked :-< There is >> a zoom command for the canvas which is supposed to provide "automatic" >> zooming, but I couldn't make it work. > > Really? Is the code still in there? No, sorry, I blasted it away because, as I mentioned, it was really ugly. All I did was add a zoom in and zoom out option to the menu and attach them to workspace functions that call set_pixels_per_unit(). I can remake it really easy if you want it. But it was *really* ugly :-) Brad From jarl at casema.net Fri Apr 7 06:40:15 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] Re: Security model References: <200004071042.GAA173090@archa11.cc.uga.edu> Message-ID: <38EDBB0F.3B0BE23F@casema.net> > > The only problem with remote DL's is that the (local) root DL must > know about > > that remote one in order to authoritized it. > > Okay, I think we are saying the same thing--that a local dl has to > accept a connection from a remote dl and get it authorized to use the > local bl. This will be occuring in a (not yet defined) dl->dl corba > connection. Right. > > > > (note: the transported data will be encrypted with the DL password > as key.) > > Man, Jarl, you are awesome! This just helped me figure out a problem I > was having with secure password storage in the dl. Thanks! > N.P. , gonna forward this to a lot of people :-) > > > > > Maybe this new field of the uriS will make this possible? > > so it will be like this (simplyfied): > > struct uriS { > > long instaceID; > > long groupID; //aint the same as the unix 'group' !! > > long subnetID; > > long nodeID; > > }; > > > > Giving any lead? > > Okay, so a group is "smaller" than a instanceID, and groups subnets > and nodes and not users. Am I following you correctly? > Yep! Sorry about the short answers, kinda buzy @work. From jarl at casema.net Fri Apr 7 17:13:28 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] UI\DL support BL\PL requests? References: <200004071135.HAA121862@archa12.cc.uga.edu> Message-ID: <38EE4F77.38C4A187@casema.net> HI, I think we got enough security complexities for a while, so I'll torture you with a new topic 8) In GMS I've not only the engine serving request out of the GUI, but also the other way around. Like when the processing part detects a data flow which is a deadend, it will trigger an event in the GUI. I can imaging various other random events inside the VSH PL and BL that need to be passed to the DL and UI. I'm wondering if Loci allowes such abilities? Or should I put all the logic for handling the error\notify events inside the BL? It seems a good thing, and I'm willing to implement it, but I needs some feedback first ofcourse :) jarl From bizzaro at geoserve.net Fri Apr 7 18:47:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] UI\DL support BL\PL requests? References: <200004071135.HAA121862@archa12.cc.uga.edu> <38EE4F77.38C4A187@casema.net> Message-ID: <38EE657C.1FECF75A@geoserve.net> jarl van katwijk wrote: > > In GMS I've not only the engine serving request out of the GUI, > but also the other way around. Like when the processing part > detects a data flow which is a deadend, it will trigger an event > in the GUI. I can imaging various other random events inside the > VSH PL and BL that need to be passed to the DL and UI. > I'm wondering if Loci allowes such abilities? Or should I put all > the logic for handling the error\notify events inside the BL? It > seems a good thing, and I'm willing to implement it, but I needs > some feedback first ofcourse :) You're aware that Loci's front 'listens' to a stream of XML commands from the middle. All communication, including that of unexpected error messages, travels through that stream. But, right now the mechanism is not threaded. So, the middle literally cannot do anything until the front issues a command, and visa versa. And I believe the front doesn't listen for unexpected messages (is that right, Brad?). IOW, the middle cannot YET trigger an event in the front. It was planned, though. I don't know if the logic for this belongs in the DL or BL. But, of course, the communication should pass through the DL before going to the front. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri Apr 7 18:02:38 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:43 2006 Subject: [Pipet Devel] UI\DL support BL\PL requests? References: <200004071135.HAA121862@archa12.cc.uga.edu> <38EE4F77.38C4A187@casema.net> <38EE657C.1FECF75A@geoserve.net> Message-ID: <38EE5AFE.AA852DEE@casema.net> > > > > In GMS I've not only the engine serving request out of the GUI, > > but also the other way around. Like when the processing part > > detects a data flow which is a deadend, it will trigger an event > > in the GUI. I can imaging various other random events inside the > > VSH PL and BL that need to be passed to the DL and UI. > > I'm wondering if Loci allowes such abilities? Or should I put all > > the logic for handling the error\notify events inside the BL? It > > seems a good thing, and I'm willing to implement it, but I needs > > some feedback first ofcourse :) > > You're aware that Loci's front 'listens' to a stream of XML commands from the > middle. All communication, including that of unexpected error messages, > travels through that stream. > No, I didn't knew that.. so there's no problem. Good. I leave gms\BL the way it is now, you do so 2 and we only need to define the communication some day. Not now please :-) I'm just orientating if we still have mayor design differences. > But, right now the mechanism is not threaded. So, the middle literally cannot > do anything until the front issues a command, and visa versa. And I believe > the front doesn't listen for unexpected messages (is that right, Brad?). IOW, > the middle cannot YET trigger an event in the front. It was planned, though. That is enough for now :) > I don't know if the logic for this belongs in the DL or BL. But, of course, > the communication should pass through the DL before going to the front. > I think events once they are triggered in a layer, it will 'travel upwards' to the UI. But it might be handled by a layer before it reaches the UI. jarl From bizzaro at geoserve.net Fri Apr 7 19:04:35 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Security model References: <200004061355.JAA110988@archa10.cc.uga.edu> Message-ID: <38EE6983.1AE24700@geoserve.net> Brad Chapman wrote: > > > 1a- BL's authenticate DL's for applying XML into > > the processing engine. > > 1b- The 1st DL loggin into the BL is automatically > > the 'root' DL, > > and has the ability to grant other DL's > > access. > > 1c- Other DL's (local and remote) can connect via > > CORBA after > > the root DL has granted them access. Okay, how many fronts (GUI's) per DL are we talking about here? One or more? > > 1d- DL's can connect to multiple BL's. By means of the DL layer again? Or directly? > > 1e- BL nodes (or: VSH subnets) can communicate > > with other BL nodes > > only if both nodes have the same parent > > DL. Meaning the BL nodes are local? > > 2a- a DL authenticates other DL's for access to > > its nodes\subnets. > > 2b- DL's can connect to other DL's and > > upload\download XML > > documents outof and into. > > 2c- No DL can connect to the root DL, so no > > non-root DL has ability 2a. I don't get it. If the root DL is the first to connect, how can another DL connect? Nothing can connect to the root DL. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 7 19:11:31 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> Message-ID: <38EE6B23.D1AC98A8@geoserve.net> Brad Chapman wrote: > > > 1d- DL's can connect to multiple BL's. > > Okay. This will be through the mechanism we already have for 1a. This still seems backwards to me. I can understand multiple DL's for each BL, but what will multiple BL's be used for? > This makes a lot of sense for security reasons. This way, no one can > remotely get access to a root DL. So before the local DL starts > allowing remote DLs access, the local root DL will have to create a > new DL to allow this access. Am I reading you right on this one? So, there is a second DL created for additional connections to be made? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 7 19:23:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> <38ECF06C.F84BA7B9@casema.net> Message-ID: <38EE6DDB.92C2B527@geoserve.net> jarl van katwijk wrote: > > The only problem with remote DL's is that the (local) root DL must know about > that remote one in order to authoritized it. Hmmm. So, DL do authorization, but the connection between remote DL's and the local BL is direct? > OK, so this means will will have a system that is like the unix user\group > system, > only groups have passwords too in VSH! > > group ~~ BL level (DL id & DL password give access to whole set of subnets > and nodes that are childs of that DL) > user ~~ DL level (??? id & ??? password give access to subset of the > subnets and nodes that are childs of that DL) I'm not sure I understand why group is BL level and user is DL level. And, why would you have a group password? The reason Unix doesn't have group passwords is because everyone must log in as a user anyway. Are you saying someone can have group access without logging in as a user? > Yeppo! > The root DL will only be there to grant others access and do some very-very-very > basic subnet processing. > The most work will spawn out of other DL's. Okay...I think I understand. > No, they have access to the nodes created with THEIR DLid. > And yes, this makes it possible to have multiple logins on the same DLid. > To get access to another DL's nodes, use login 'level' (?) 2. > We should therefor deside if it can be possible for a DL to login to another DL > and to a BL at the same time. I didn't though about the consequences yet.. You mean in addition to logging into the root DL? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri Apr 7 18:25:04 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Security model References: <200004061355.JAA110988@archa10.cc.uga.edu> <38EE6983.1AE24700@geoserve.net> Message-ID: <38EE6040.A6A638BF@casema.net> > > > > 1d- DL's can connect to multiple BL's. > > By means of the DL layer again? Or directly? Directly. > > > > > 1e- BL nodes (or: VSH subnets) can communicate > > > with other BL nodes > > > only if both nodes have the same parent > > > DL. > > Meaning the BL nodes are local? No, a DL can connect to multiple BL's, so it can create nodes on remote systems too. > > > > 2a- a DL authenticates other DL's for access to > > > its nodes\subnets. > > > 2b- DL's can connect to other DL's and > > > upload\download XML > > > documents outof and into. > > > 2c- No DL can connect to the root DL, so no > > > non-root DL has ability 2a. > > I don't get it. If the root DL is the first to connect, how can another DL > connect? Nothing can connect to the root DL. OK, but the root DL is the only DL that can grant other DL's access. This 'root' will practically be most of the time invisible to the user. So it must open up the BL for at least one other DL for VSH to be usable :) From jarl at casema.net Fri Apr 7 18:26:59 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> <38EE6B23.D1AC98A8@geoserve.net> Message-ID: <38EE60B3.B97A26DC@casema.net> > > > 1d- DL's can connect to multiple BL's. > > > > Okay. This will be through the mechanism we already have for 1a. > > This still seems backwards to me. I can understand multiple DL's for each BL, > but what will multiple BL's be used for? For spreading the nodes across remote systems. On each system a DL is logged into it can place it's nodes, or the BL can move the subnets across systems. From bizzaro at geoserve.net Fri Apr 7 19:33:44 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004071042.GAA173090@archa11.cc.uga.edu> Message-ID: <38EE7058.21456DE6@geoserve.net> Brad Chapman wrote: > > > (note: the transported data will be encrypted with the DL password > as key.) > > Man, Jarl, you are awesome! This just helped me figure out a problem I > was having with secure password storage in the dl. Thanks! What sort of encryption are we talking about? > > OK, so this means will will have a system that is like the unix > > user\group system, only groups have passwords too in VSH! > > This sounds like a good plan to me. Jeff, does this jive with your > security ideas? I just have that one question about group passwords. Will users be able to log in to a group without logging in as a user? > > No, they have access to the nodes created with THEIR DLid. > > And yes, this makes it possible to have multiple logins on the same > DLid. > > To get access to another DL's nodes, use login 'level' (?) > > Okay, I think I understand your point, although I'm not sure what you > mean by login level... I think he means the user is granted a higher level of access, being able to tap into other DL's...directly? Doesn't BL->BL communication occur as BL->DL->Internet->DL->BL? Then, what will BL->DL->Internet->DL->DL->BL provide, other than additional access? > This makes my head hurt :-) I think we should keep it simple for the > time being. I think the only idea about of one dl being able to log > into another was so one dl could control the other (ie. you could > control the gnome gui display using the (not yet developed) speech > recognition user interface. Am I right on this Jeff, or did you have > bigger ideas of two dls connecting? Okay, now I'm confused. I thought we were going to have multiple fronts for each DL. Or are you talking about one front per DL? For Loci, I was planning on the multiple fronts being all local to the middle. > > Maybe this new field of the uriS will make this possible? > > so it will be like this (simplyfied): > > struct uriS { > > long instaceID; > > long groupID; //aint the same as the unix 'group' !! > > long subnetID; > > long nodeID; > > }; > > > > Giving any lead? > > Okay, so a group is "smaller" than a instanceID, and groups subnets > and nodes and not users. Am I following you correctly? Can we get a clear definition of a 'group' then? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 7 19:37:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> <38EE6B23.D1AC98A8@geoserve.net> <38EE60B3.B97A26DC@casema.net> Message-ID: <38EE7124.61493A2E@geoserve.net> jarl van katwijk wrote: > > For spreading the nodes across remote systems. > On each system a DL is logged into it can place it's nodes, or the BL can move > the subnets across systems. But doesn't BL->BL communication have to occur as BL->DL->Internet->DL-BL? Brad argued for Loci to have only one core running per system. Are you saying we can have multiple BL's per system? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 7 19:42:26 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Security model References: <200004061355.JAA110988@archa10.cc.uga.edu> <38EE6983.1AE24700@geoserve.net> <38EE6040.A6A638BF@casema.net> Message-ID: <38EE7262.75B70E05@geoserve.net> jarl van katwijk wrote: > > > > > 1d- DL's can connect to multiple BL's. > > > > By means of the DL layer again? Or directly? > > Directly. But if DL's connect directly to BL's, then how is authentication done? I thought the root DL handled that. Do you really mean directly, or do you mean through the root DL? > > I don't get it. If the root DL is the first to connect, how can another DL > > connect? Nothing can connect to the root DL. > > OK, but the root DL is the only DL that can grant other DL's access. > This 'root' will practically be most of the time invisible to the user. > So it must open up the BL for at least one other DL > for VSH to be usable :) Should that then be reworded as 'nothing can connect AS the root DL'? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri Apr 7 18:44:17 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> <38ECF06C.F84BA7B9@casema.net> <38EE6DDB.92C2B527@geoserve.net> Message-ID: <38EE64C1.1AC52D7@casema.net> > > > > The only problem with remote DL's is that the (local) root DL must know about > > that remote one in order to authoritized it. > > Hmmm. So, DL do authorization, but the connection between remote DL's and the > local BL is direct? > Direct? a DL must authenticate to the BL if this is what you want to hear (?). > > I'm not sure I understand why group is BL level and user is DL level. group : a BL allows ALL nodes\subnets(?\commands?) from a DL once it's logged in. user: a DL grants another DL only partical access to the node space it has inside the BL So a DL can only grant access to its own nodes, a BL grants all-or-nothing to the nodes. This is happening when the UI is closed and the nodes it has created are still active. > > And, why would you have a group password? The reason Unix doesn't have group > passwords is because everyone must log in as a user anyway. Are you saying > someone can have group access without logging in as a user? > Yes, I think we should see the 'group' as the main authorisation 'level', the 'USER level' is more detaillistic, it's only a part of the regulair used access, only a subset. I'm not to happy about the naming, you can see why. > > We should therefor deside if it can be possible for a DL to login to another DL > > and to a BL at the same time. I didn't though about the consequences yet.. > > You mean in addition to logging into the root DL? No, as this situation : - DL1 is logged into BL1 - DL2 is logged into BL1 - DL2 also is logged into DL1, so it's able to use some of DL1's nodes. This would make it possible for DL2 to combine it's nodes to DL1's nodes. This situation just makes me expect security holes.. i'm not sure yet. jarl From jarl at casema.net Fri Apr 7 18:48:27 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004071042.GAA173090@archa11.cc.uga.edu> <38EE7058.21456DE6@geoserve.net> Message-ID: <38EE65BB.B942AF9B@casema.net> > > Man, Jarl, you are awesome! This just helped me figure out a problem I > > was having with secure password storage in the dl. Thanks! > > What sort of encryption are we talking about? > The best :-) I suggest not coding this ourselfs. From jarl at casema.net Fri Apr 7 18:51:44 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> <38EE6B23.D1AC98A8@geoserve.net> <38EE60B3.B97A26DC@casema.net> <38EE7124.61493A2E@geoserve.net> Message-ID: <38EE6680.A7843C0B@casema.net> > > the subnets across systems. > > But doesn't BL->BL communication have to occur as BL->DL->Internet->DL-BL? > Not when the communication is between 2 subnets that both have the same DL as parent. All the other dataflows will be routed trough the DL. > > Brad argued for Loci to have only one core running per system. Are you saying > we can have multiple BL's per system? No, just one BL and PL locally. More wont make sense, but is possible. From bizzaro at geoserve.net Fri Apr 7 19:59:02 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004071107.HAA53566@archa10.cc.uga.edu> Message-ID: <38EE7646.D74E4733@geoserve.net> Brad Chapman wrote: > > We definately need to work out how this should work, but I'm still > gunning for having stored loci have a tag that reflects their group, > and then have another storage file that associates remote logins with > groups. This is analagous to the unix filesystem, but doesn't use it, > because I feel like then the vsh user will have to configure their > local filesystem outside of a running vsh implementation, while the > other way will allow this configuration within a vsh (as an extension > of your development environment idea). We could also tie the vsh > development environment with assigning groups in the local filesystem, > but it seems like we are abusing the meanings of groups to make them > extend to remote users. Isn't all the unix group and permission stuff > meant for configuring a local environment, and not a remote one? You're right that the Unix authentication and file systems cannot manage a distributed system like ours. > I've been reading into this more. I don't think the naming service > will work for a distributed pseudo-filesystem. Although it is > organized in a tree-like structure like the filesystem, it is meant > for publishing corba objects. Each subnet or node that is available on > a computer will not be a different corba object, but rather will be > represented as XML, so we can't publish these objects in a naming > service (or any other service for that matter). This is why I think > the way things should work is that the naming service is used to > locate remote hosts (like dns) and then you should query them to see > the full list of nodes that are available. I while ago I mentioned JungleMonkey: http://www.junglemonkey.net/ I think it is a distributed filesystem like Napster (I know little about Napster). I'd like us to take a VERY SERIOUS look into making a Napster-like system. We can set up a central server at The Open Lab that can register every node in every VSh system on the Internet. What do you think? > In addition to this, we could also utilize the trading service, > which publishes objects by description (rather than by name). So a vsh > instance could publish their connection object, and then associate > the description of the object with the publically available nodes > (along with other information about the computer such as processing > power, etc.). Then a user could search for a particular subnet or node > (a particular program) and find out where it is available. Perhaps a bit like Napster. I like the idea of cumputers being registered for power, etc. > So, stealing some analogies from the corba documentation, our > naming service would be like the white pages, where you can find other > computers by their known name, and the trading service would be like > the yellow pages, where you can look up the computers by the services > they offer. It still would require a central registry, like DNS and.....hmmmm.....could it be....NAPSTER?! :-) > I know this isn't your vision for how things should work, but > seems to implement the same ideas, only using already designed corba > services. You know more about the services CORBA can offer. Actually, what you described is more like an earlier vision I had for Loci, where there was a central 'hub' for locating loci. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri Apr 7 19:01:35 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Security model References: <200004061355.JAA110988@archa10.cc.uga.edu> <38EE6983.1AE24700@geoserve.net> <38EE6040.A6A638BF@casema.net> <38EE7262.75B70E05@geoserve.net> Message-ID: <38EE68CF.5D46F547@casema.net> > > But if DL's connect directly to BL's, then how is authentication done? I > thought the root DL handled that. Do you really mean directly, or do you mean > through the root DL? DL authenticate them self to the BL. So the 'group' and the 'user' (aargg, darn names) id + passwords lists will be located in 2 different layers. > > > > OK, but the root DL is the only DL that can grant other DL's access. > > This 'root' will practically be most of the time invisible to the user. > > So it must open up the BL for at least one other DL > > for VSH to be usable :) > > Should that then be reworded as 'nothing can connect AS the root DL'? Yep! But [ sorry:) ] some DL might get access to this root DL at 'user' level and so getting SOME access to the root 'group'. From bizzaro at geoserve.net Fri Apr 7 20:10:32 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: Security model References: <200004061355.JAA112514@archa10.cc.uga.edu> <38ECF06C.F84BA7B9@casema.net> <38EE6DDB.92C2B527@geoserve.net> <38EE64C1.1AC52D7@casema.net> Message-ID: <38EE78F8.222B298C@geoserve.net> jarl van katwijk wrote: > > > Hmmm. So, DL do authorization, but the connection between remote DL's and the > > local BL is direct? > > Direct? a DL must authenticate to the BL if this is what you want to hear (?). Okay. > > I'm not sure I understand why group is BL level and user is DL level. > > group : a BL allows ALL nodes\subnets(?\commands?) from a DL once it's logged in. > user: a DL grants another DL only partical access to the node space it has inside the > BL > > So a DL can only grant access to its own nodes, a BL grants all-or-nothing to the > nodes. This is happening when the UI is closed and the nodes it has created are still > active. I understand. But I think 'user' and 'group' might be confusing to Unix people. > > And, why would you have a group password? The reason Unix doesn't have group > > passwords is because everyone must log in as a user anyway. Are you saying > > someone can have group access without logging in as a user? > > > > Yes, I think we should see the 'group' as the main authorisation 'level', the 'USER > level' is more detaillistic, it's only a part of the regulair used access, only a > subset. > > I'm not to happy about the naming, you can see why. :-) Yes, we should work on some better names for those two. > > > We should therefor deside if it can be possible for a DL to login to another DL > > > and to a BL at the same time. I didn't though about the consequences yet.. > > > > You mean in addition to logging into the root DL? > > No, as this situation : > > - DL1 is logged into BL1 > - DL2 is logged into BL1 > - DL2 also is logged into DL1, so it's able to use some of DL1's nodes. > > This would make it possible for DL2 to combine it's nodes to DL1's nodes. > This situation just makes me expect security holes.. i'm not sure yet. Hmmmm. I see. It's an interesting idea. I think it adds an extra dimension to the application, but it MAY add some security problems, as you say. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri Apr 7 19:15:37 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> Message-ID: <38EE6C18.4D5135BF@casema.net> > I while ago I mentioned JungleMonkey: > > http://www.junglemonkey.net/ > > I think it is a distributed filesystem like Napster (I know little about > Napster). I'd like us to take a VERY SERIOUS look into making a Napster-like > system. We can set up a central server at The Open Lab that can register > every node in every VSh system on the Internet. What do you think? > I've better feelings about a peer-2-peer structure, like gnutmeg - http://sourceforge.net/project/?group_id=3965 Maybe only register the locations (inet addresses) of the systems where instaces of VSH are running? > > > > So, stealing some analogies from the corba documentation, our > > naming service would be like the white pages, where you can find other > > computers by their known name, and the trading service would be like > > the yellow pages, where you can look up the computers by the services > > they offer. > > It still would require a central registry, like DNS and.....hmmmm.....could it > be....NAPSTER?! :-) Seen gnutella already? This project handles all files, not just mp3's. From bizzaro at geoserve.net Fri Apr 7 20:17:06 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] summary for web References: <200004071118.HAA158284@archa11.cc.uga.edu> Message-ID: <38EE7A82.253152BC@geoserve.net> Brad Chapman wrote: > > > Should the DL be split into 2 parts then? > > What do you mean by this? My plan was that the dl should be split into > two parts programmatically (ie. two different servers with APIs). I > think the two different objects will need to interoperate quite a bit, > and haven't though about separating them formally with corba or > something. Yeah, I'm just thinking that if the DL is 2 parts in functionality, maybe would could make the 2 parts different programs and give them different names. > > Better support for multithreading is something the ORBit developers > > are working on? > > You're asking me about gnome development? :-) I looked through the > gnome-devel archives and didn't seem much mention of orbit development > (there is an orbit list but I couldn't find an archive for it). From > my rough estimation, it seems like orbit isn't under continual > development by anyone, but is enhanced when a general need for > enhancement arises in gnome. Threading issues are on the out of date > (the developers' words, not mine) todo list in cvs, but I have no > concept of when this might be addressed (probably as soon as someone > wants it bad enough to hack on it). I don't see any mention of > implementing a trading service, and I kind of doubt this is on many > people's mind since I think this is what gnorba and bonobo are meant > to do. But I'm just guessing at all this. If anyone knows better, I'd > love to hear it. I used to subscribe to the ORBit list. It was (and still is AFAIK) maintained by this guy Elliot over at RHAD Labs. I wouldn't say ORBit development has died. It's a very important part of Gnome. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri Apr 7 19:23:21 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] summary for web References: <200004071118.HAA158284@archa11.cc.uga.edu> <38EE7A82.253152BC@geoserve.net> Message-ID: <38EE6DE9.77441CFB@casema.net> > > I used to subscribe to the ORBit list. It was (and still is AFAIK) maintained > by this guy Elliot over at RHAD Labs. I wouldn't say ORBit development has > died. It's a very important part of Gnome. It surely aint dead. I've been subscribed to the list for some months now. But I must admit I'm not really reading all the postings :) Get the impression the work is about cleaning up the 0.5.0 release. From bizzaro at geoserve.net Fri Apr 7 20:36:58 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Re: window sill References: <200004071135.HAA121862@archa12.cc.uga.edu> Message-ID: <38EE7F2A.A3B0694A@geoserve.net> Brad Chapman wrote: > > > No, I was suggesting to you that the 'view we have now' (the > > workspace normal view) replace the GtkCTree view for taking > > listings of directories. The composite GUI will look like a > > regular Gtk interface. > > Okay...how can you then distinguish between moving a locus from > one workspace to another via dnd, and copying a locus unto a new > workspace via dnd (ie. if you are copying a saved locus onto to the > workspace to use, or if you are dragging a directory out of a > representation of a local filesystem)? Just as you would do any DnD between objects. The workspaces are all Gtk/Gnome objects. > Will the workspace need to keep > track of what kind of information it is holding? The middleware (the 3 layers) will need to keep track of what node is where. The front will do it in a more ephemeral way (using temporary GUI objects). > Similary, a > composite representing a save directory or local filesystem will need > to react different to loci that are dragged into them then a "regular" > workspace would. Why? How will they act differently? > I guess we would probably need to define two > different workspace types in the code. Maybe, if there really is a difference between a 'storage node' and a 'working node'. I say there is no difference. And, since we're making our own distributed pseudo-filesystem, it won't be such a stretch of the imagination as it would be with a Unix filesystem: We can MAKE IT so that there is no difference. > Also, how will a workspace be populated with gui representations > of loci if you, for instance, open up a save container full of loci? > Just stick them with equal spacing throughout the workspace, like > opening a directory on a mac? Yep. I'd hide the links/connectors by default, so it would look EXACTLY like a Mac folder in 'large icon' view. Hiding links would serve another purpose I recently realized. Recall how non-connected links mean the I/O is from/to the parent node, and if you want a true dataflow 'dead-end', you'd need to cap it off somehow. I would make hidden links mean dataflow dead-ends. Going back to the workspace as a 'storage node', it would be important to hide the links of stored nodes. One may store dozens or hundreds of nodes in such a place, and we wouldn't want all of those non-connected links to end up on the parent node ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 7 20:44:09 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Security model References: <200004061355.JAA110988@archa10.cc.uga.edu> <38EE6983.1AE24700@geoserve.net> <38EE6040.A6A638BF@casema.net> <38EE7262.75B70E05@geoserve.net> <38EE68CF.5D46F547@casema.net> Message-ID: <38EE80D9.B8A29C15@geoserve.net> jarl van katwijk wrote: > > > But if DL's connect directly to BL's, then how is authentication done? I > > thought the root DL handled that. Do you really mean directly, or do you mean > > through the root DL? > > DL authenticate them self to the BL. Directly? Wait a minute. I thought that the root DL handled the authentication of new DL's connecting to the BL, and that the connection is indirect, through the root DL. Is that wrong? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 7 20:57:41 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:44 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> Message-ID: <38EE8405.F64F8E52@geoserve.net> jarl van katwijk wrote: > > I've better feelings about a peer-2-peer structure, like > gnutmeg - http://sourceforge.net/project/?group_id=3965 > > Maybe only register the locations (inet addresses) of the systems where instaces > of VSH are running? Napster has an interesting security feature, even if it was unintentional: You don't connect directly to a remote system. You connect to the Napster server, and the Napster server connects to the remote system. How would something like that jive with our plans? > Seen gnutella already? > This project handles all files, not just mp3's. Yes I have. This is the sort of thing I'm talking about. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Sat Apr 8 06:17:06 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> Message-ID: <38EF0722.71DC4559@casema.net> > > > > I've better feelings about a peer-2-peer structure, like > > gnutmeg - http://sourceforge.net/project/?group_id=3965 > > > > Maybe only register the locations (inet addresses) of the systems where instaces > > of VSH are running? > > Napster has an interesting security feature, even if it was unintentional: You > don't connect directly to a remote system. You connect to the Napster server, > and the Napster server connects to the remote system. How would something > like that jive with our plans? > Those are the good things, but what about the networkload a central server will get? And what if that server crashes? bye, jarl From chapmanb at arches.uga.edu Sat Apr 8 10:36:04 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] Distributed Filesystems WAS Choice of ORB implementations Message-ID: <200004081438.KAA111832@archa10.cc.uga.edu> I'm going to try to summarize some of the stuff Jarl and Jeff have been talking about and then offer my opinions. Please smack me up if I have represented anyone wrong. My quick summary: Okay, so I originally proposed a way to use the naming and trading services of corba to manage remote vsh instances and "search" for specific nodes within registered nodes. Jeff and Jarl have proposed an alternative way of doing things using a distributed filesystem approach. The choices that were mentioned for implementing this were: Jungle Monkey -> http://www.junglemonkey.net/ Gnutmeg -> http://sourceforge.net/project/?group_id=3965 My thoughts: I guess I sort of see what you guys are thinking about, but I don't really understand exactly how you are proposing to work this type of system into vsh. Let me try to think through it: 1. There is a central server (at TOL) that all instances of vsh will register with. 2. This central server will allow services for browsing and searching the registered vsh instances (like the screenshots on the Jungle Monkey page). 3. Each vsh instances will make available files that remote users can browse. Here, I don't really understand what kind of files you want to make available--xml files describing available nodes and subnets? 4. A user looking through the files finds a subnet they want to run on a remote vsh implementation. Then they need to connect to the remote vsh system (via CORBA) and request the available subnet information. How does the user get the object reference for the remote system? 5. Then things would work the same in both of the proposals. The local user would incorporate the remote node into their work flow diagram and submit the work flow diagram for processing, and then during processing all of the dl -> bl and bl -> dl and dl -> dl stuff would have to happen to do the proper processing (I won't go into that again here since that's not what we are discussing). So, do I have it semi-right? What are your guys ideas for how this will work? I also have a couple of other issues: 1. As Jarl mentioned, the distributed filesystem plan depends heavily on a central server to handle everything, and then we get into problems with load on the server and what happens if it goes down. Although I would propose that we start _initially_ with a central naming and trading service, it is possible (ie. has been done--not that I can do it yet :) to distribute these services over multiple computers. How does the distributed filesystem plan scale up? 2. How does authentication work for viewing everyones files? Does all this occur in the central server? If so, it seems like this might make the central server a big target for cracking, since if you could do so you would have access to everyone's files. For the corba services plan, the authentication would occur at each vsh instance, which might at least make things less of a target. 3. Jeff, you wrote this: > Napster has an interesting security feature, even if it was unintentional: You > don't connect directly to a remote system. You connect to the Napster server, > and the Napster server connects to the remote system. How would something > like that jive with our plans? Does this imply that every connection and filesharing and everything has to funnel through the main server? For what I want to use vsh for, this would be a serious pain. For a biological example (sorry, that's all I can think of :-), lets say I had three Suns running local BLAST servers and had 30,000 sequences to query. I'd like to be able to use vsh to "distribute" the request over the three Suns (ie. 10,000 on each) as a kind of cheap cluster or something. This is entirely a local use (and could even be occuring on one local network), but would I have to funnel all the connections through some remote central server? I don't like this, and would rather not even have to register my Suns with the remote server. The thing I like about the corba services are that they are voluntary and more of a convenience--if you could get a hold of on object instance in another way, you wouldn't even have to use them. How will the distributed filesystem plan work? Sorry to be so long--thanks if you read through all of this :-) Brad From bizzaro at geoserve.net Sat Apr 8 16:03:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] Choice of ORB implementations References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> <38EF0722.71DC4559@casema.net> Message-ID: <38EF90AF.A9276ECB@geoserve.net> jarl van katwijk wrote: > > Those are the good things, but what about the networkload a central server will get? > And what if that server crashes? The organization was going to set up some big iron for doing this with Loci. We were hoping to get a computer donated from Compaq, IBM, or whoever. We also have a pretty hefty network available now: a fiber -optic T3 backbone that we can run some 100baseT lines off of. Server crashes would of course be bad, but with the right equipment, we could get 4 nines (99.99%) uptime. We could also give away the source code for setting up a central server and have others set up their own. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Mon Apr 10 01:26:49 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] VSH Security model References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> <38EF0722.71DC4559@casema.net> <38EF90AF.A9276ECB@geoserve.net> Message-ID: <38F16619.E3147BB7@casema.net> Hi all, I made a start writing down the security model vsh will get, it's not complete yet, so please read it and comment on it, i'll work some more on it later today. bye, jarl -------------- next part -------------- VSH Security model 9-4-2000 Changelog: 10-4-2000: Jarl van Katwijk, 1st draft text ------------------ Definitions: 1) VSH is implemented by 4 layers, 2) LAYERS are concidered isolated besides the communication api, 3) NODES are the neurons making up subnets and complete structures, 4) SUBNETS are sets of nodes that are clustered for some reason, Layers description: 1) UI, User Interface layer, graphical user front end or batch script. 2) DL, Definition layer, coordination engine for scheduling UI's and partial sharing of structure data. Logs into the BL. 3) BL, Bropkering layer, engine for handling subnets, authentication of DL's and parsing to the PL. Wraps application plugins. 4) PL, Processing layer, holds the nodes, wraps (terminal?) applications and performs nodes processing. Layers communications: 1) UI<->DL communication will go by sockets 2) DL ->BL communication will go though the dl2bl corba orb 3) BL ->DL communication will go though the bl2dl corba orb 4) BL<->PL communication will go by linking the PL libraries Authentication system: 0) Localhost has running VSH core, cq a BL\PL process. 1) UI's spawn a new DL. 2) DL's login to BL by their dlID and blPassword. 2a) The 1st DL loggin into a BL becomes the root DL and has the ability to authorize other DL's to log into the BL. (AddDL();) 2b) All subnets created by a DL are marked by the idDL and have the same login ability (or: idDL+blPassword) as their parent. Subnets can therefor be relocated or mirrored inside a remote BL\PL process. 3) DL's can login to other DL's by dlID and dlPassword. Note dlPassword is NOT blPassword. These are 2 seperate id+password tables. 3a) A DL can only interact\mutate it's 'own' nodes 3b) A DL which is logged into another DL can interact & mutate all nodes of the host DL. From bizzaro at geoserve.net Mon Apr 10 09:28:32 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] VSH Security model References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> <38EF0722.71DC4559@casema.net> <38EF90AF.A9276ECB@geoserve.net> <38F16619.E3147BB7@casema.net> Message-ID: <38F1D700.1611D318@geoserve.net> jarl van katwijk wrote: > > I made a start writing down the security model vsh will get, > it's not complete yet, so please read it and comment on it, > i'll work some more on it later today. It would be good to put this up on the web. Perhaps I could link the layer summaries off of this. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 11:24:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] COLIMATE Message-ID: <38F1F23F.741528F3@geoserve.net> This is very similar to the approach I want to take with 'command-line construction' (Brad will recall many e-mails sent in my attempt to describe my approach): http://www.cnb.uam.es/~bioinfo/Colimate/Extra_Docs/ You can see from the screenshots that command-line options are translated into GUI widgets. The major difference between Colimate and my own plans for vsh/Loci command-line construction, is that the definition of command-line options (or the construction of the interface) is done by connecting nodes. Jeff From bizzaro at geoserve.net Mon Apr 10 16:07:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] chat Message-ID: <38F23479.CD8A771D@geoserve.net> I'm looking over the IRC buffer from the conversation Jarl and Brad had while I was outside doing yardwork. I want to make a couple comments. ------------------------------------------------ and remember: I had to please jeff by the napster proposal, I'd like a peer-2-peer solution and a very limited cetralised system but that doesn't seem possible (technically) right now Well, we'll have to see. I think it's just to early to know for sure--things will probably become clearer as we get nearer to that stage. At least, that's what I hope :) as I said: i'll experiment with getting as much peer-2-peer as possible.. maybe you can look around for such a system too jer, it's still a long time away these constructions Yeah, I really want the peer-2-peer stuff to be working, ------------------------------------------------ Brad, if the Napster-like central server can be distributed with vsh, or at least be made available publicly, then people can make peer-2-peer connections. All they have to do is specify which 'Napster-like' server they want to use as a filesystem, and it can be one on your buddy's computer. And I really see this Napster-like server as being vsh's filesystem. Heck, if we distribute this 'filesystem' with every copy of vsh, the filesystem can hold your local nodes. But what we can do at The Open Lab is set up a large repository of nodes...but use the same code that comes with every distribution of vsh. You know, even when you log on to IRC, you're using a central server to host the connection between 2 computers. But you can choose one of many servers. Why not do the same with vsh? ------------------------------------------------ It will make Jeff a lot happier too, because I don't think he's gotten it compiled yet... hehe you know what os jeff uses? linux (redhat, I think), so I'm not sure the problem. what do you use? slackware linux, but hardly anything is original anymore :) hmm strange, gms was tested on redhat. nah, never mind, 0.4.0 should have automake anyway ------------------------------------------------ The problem with compiling GMS is that the location of a (gtk?) header in the library changed since the version Jarl last compiled GMS with. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon Apr 10 17:39:34 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] chat Message-ID: <200004102142.RAA74034@archa10.cc.uga.edu> [snip ..central server conversation...] > Brad, if the Napster-like central server can be distributed with vsh, or at > least be made available publicly, then people can make peer-2-peer > connections. All they have to do is specify which 'Napster-like' server they > want to use as a filesystem, and it can be one on your buddy's computer. > > And I really see this Napster-like server as being vsh's filesystem. Heck, > if > we distribute this 'filesystem' with every copy of vsh, the filesystem can > hold your local nodes. But what we can do at The Open Lab is set up a large > repository of nodes...but use the same code that comes with every > distribution > of vsh. Jeff, I want to use vsh/loci as a "cheap cluster type thingy" to distribute groups of expensive time consuming processes over multiple computers. The idea of a central server mediating peer2peer connections in the napster manner you are describing is definately not compatible with this vision. I think the napster idea is great as a way to distribute "pre-built scripts" for running programs, and I definately support its use for this. But I don't see the point in having a central server mediating all of my connections among local machines. I think we will need some kind of central naming service server to distribute corba instances, but I want to keep a central server lightweight and disposable (ie. you don't need to connect to it if you can get the object reference in another manner). I really just don't see the need for a central server in the manner that you describe. Can you explain why you think it is better to funnel all connections through a server? > You know, even when you log on to IRC, you're using a central server to host > the connection between 2 computers. But you can choose one of many servers. > Why not do the same with vsh? IRC uses a central server to mediate a connection between two client computers. By contrast, each vsh instance is both a client (that can connect to other vsh instances) and a server (that can recieve requests from othe vsh servers). Lets just think about a simple conversation between two peers. The way I am envisioning it we can have a simple two way connection: vsh1 vsh2 ----- ----- client --> server server <-- client If we put things through a server we've got: vsh1 central vsh2 server ----- ------ ----- client --> server client ---> server server <--- client server <-- client I don't understand why we want to introduce this overhead. It seems unncessary, and like a lot of extra programming to get this central server going :) [snip...gms compilation...] > The problem with compiling GMS is that the location of a (gtk?) header in the > library changed since the version Jarl last compiled GMS with. That is the problem with building Makefiles by hand, you are almost guaranteed to have to hack them on another computer. It is nice that we will be able to try these things out on multiple computers, so hopefully we can get rid of some of the multi-platform differences early in the game. gms is almost nearly under the control of an autoconf/make build now, so hopefully things will be a lot nicer soon and everything will 'just build' in the proper gnome manner :-) Brad From bizzaro at geoserve.net Mon Apr 10 18:05:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] distributed filesystem proposal Message-ID: <38F25037.FE50BD78@geoserve.net> STORAGE There are 3 places on each computer running vsh where items are kept: in (1) permanent source storage, in (2) permanent network storage, and in (3) a temporary workspaces. (1) PERMANENT SOURCE STORAGE Each vsh system keeps the source to a node in the local file system. (a) Source can be libraries, files or programs, and they are represented by a node. (b) Source Storage can manipulated by standard Unix tools. (c) Source Storage can be made publicly available or kept private. (d) Changes to Source Storage must be reflected in the Network Storage (see below). (2) PERMANENT NETWORK STORAGE Each vsh system has its own virtual filesystem for storing nodes and networks. (a) Networks are NOT stored according to any conventional filesystem rules. (b) Networks are stored as XML representations with linkage information and information about the location of the Source. (c) Multiple volumes (more in part 3) of the Network Storage can be made and designated public or private. (d) Public volumes can be mounted by anyone across a network. But changes cannot be made. (e) Private volumes can be mounted only by those with permission. (f) A 'lock' is required on a volume for anyone who is able to change it. (g) Using a Network Storage volume requires that a connection has been established with the Storage. So, any changes made can be reflected in the Storage. (h) Volumes can be copied from one system to another. (3) VOLUMES AND TEMPORARY WORKSPACES Almost all of the functionality of a Workspace is akin to a word processor working on a document. (a) When a user mounts a Network Storage volume s/he 'opens' it, and a temporary copy of the volume is placed in a Workspace. (And the volume is locked.) (b) When a user chooses to 'save' any node or network within the volume, the changes are reflected in the volume. (c) The user can also choose to 'close' or 'unmount' a volume and make a 'new' one. (d) Workspaces are not just volumes. They are used for all networks and subnets. (d) Workspaces are not isolated. They are in fact nodes that can be placed in parent Workspaces. (Some changes in a Workspace MAY cause changes in a parent Workspace, and that needs to be considered.) (e) From the description above, Workspaces seem to be like files. But their ability to store other Workspaces makes them more like directories. PEERS About the use of a central server and peer-2-peer connections: Since every vsh system will have this filesystem, it makes no difference what computer the user connects to. So, peer-2-peer is native. On the other hand, we can set up one or more cummunity servers where volumes of Network Storages can be publicly mounted. This will make many nodes available to the new vsh user. THE PROCESS (running vsh) Vsh will work the following way, from selecting a peer to running a network (Gnome GUI specifics are included): (1) The URI of a peer is entered, and a connection is made. (2) The user can see a list of volumes available on the remote computer, which are public or private, and which are already mounted and locked by other users. (3) The user chooses to mount a private volume. This is the same as 'opening' a volume. A Workspace is made with a copy of what is in the volume. The volume is locked by the user, so no one else can use it. (4) The user makes changes to networks and nodes within the Workspace. No changes are made to the volume yet. (5) The user chooses to 'save' a node, network, or Workspace containing them (anything that can be saved). This changes the volume on the remote computer. (6) The user chooses to 'run' a network in the volume. Vsh then parses the network information kept locally. And when the source of a node needs to be contacted or downloaded, a connection is made to the Source Storage on whatever computer has the source. (7) The user chooses to 'close' or 'unmount' a volume. If changes have been made since the last save, vsh prompts the user about saving before closing. The volume is unmounted and unlocked. The Workspace disappears. Comments please. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 18:15:18 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] chat References: <200004102142.RAA74034@archa10.cc.uga.edu> Message-ID: <38F25276.9C0A04C9@geoserve.net> Brad Chapman wrote: > > I really just don't see the need for a central server in the > manner that you describe. Can you explain why you think it is better > to funnel all connections through a server? In the proposal I just sent, I outlined an approach whereby every version of vsh has the ability to share its filesystem/storage with others. This means we can set up private, peer-2-peer connections OR public, central servers. I think the system in the proposal does NOT mean that EVERYTHING is mediated through one server. EVERYTHING is mediated through whatever server has the filesystem/storage, which can be one big one on the Internet, a peer's server, or YOUR OWN LOCAL server. > Lets just think about a simple conversation between two peers. > The way I am envisioning it we can have a simple two way connection: > > vsh1 vsh2 > ----- ----- > client --> server > server <-- client > > If we put things through a server we've got: > > vsh1 central vsh2 > server > ----- ------ ----- > client --> server > client ---> server > server <--- client > server <-- client > > I don't understand why we want to introduce this overhead. It seems > unncessary, and like a lot of extra programming to get this central > server going :) In the proposal, you can have it either way: ANYTHING CAN BE ANYWHERE :-) > That is the problem with building Makefiles by hand, you are almost > guaranteed to have to hack them on another computer. It is nice that > we will be able to try these things out on multiple computers, so > hopefully we can get rid of some of the multi-platform differences > early in the game. gms is almost nearly under the control of an > autoconf/make build now, so hopefully things will be a lot nicer soon > and everything will 'just build' in the proper gnome manner :-) Cool. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 20:11:10 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] Re: distributed filesystem proposal References: <38F25037.FE50BD78@geoserve.net> Message-ID: <38F26D9E.8459068B@geoserve.net> "J.W. Bizzaro" wrote: > > (3) VOLUMES AND TEMPORARY WORKSPACES Volumes are defined as completely isolated networks. IOW, they have no inputs or outputs. They are the highest level of networks. They could be simply called 'networks' if all the networks they contain are called 'subnets'. I think this is how Overflow defines these. Also, a volume (or 'network') is an XML description of connections between subnets and nodes, as we have been saying all along. And this description resides on ONE COMPUTER (or in one BL). Brad and I were just talking about this over chat. We think a connection made to find out what volumes are available will be done via DL -> Internet -> DL -> BL connection. Mounting, opening and locking volumes are handled the same way. What differs from this mechanism is how network execution is handled. Of course, the source to a node (a program for example) can be at yet another location. In such a case, the server that stores the volume needs to make a connection to the other server. But I'm wondering if it is the remote server or the local server that should be doing the execution of the network in the volume. BOTH have copies of the network, correct? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 20:32:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] VSH Security model References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> <38EF0722.71DC4559@casema.net> <38EF90AF.A9276ECB@geoserve.net> <38F16619.E3147BB7@casema.net> Message-ID: <38F272B3.2686531E@geoserve.net> jarl van katwijk wrote: > > 2) DL, Definition layer, coordination engine for scheduling UI's and > partial sharing of structure data. Logs into the BL. > 3) BL, Bropkering layer, engine for handling subnets, authentication of > DL's and parsing to the PL. Wraps application plugins. > 4) PL, Processing layer, holds the nodes, wraps (terminal?) applications > and performs nodes processing. What actually holds the 'structure data' and manages the direct manipulation of it? > Layers communications: > 1) UI<->DL communication will go by sockets For now :-) > Authentication system: > 0) Localhost has running VSH core, cq a BL\PL process. > 1) UI's spawn a new DL. > 2) DL's login to BL by their dlID and blPassword. > 2a) The 1st DL loggin into a BL becomes the root DL and has the ability > to authorize other DL's to log into the BL. (AddDL();) > 2b) All subnets created by a DL are marked by the idDL and have the same > login ability (or: idDL+blPassword) as their parent. Subnets can > therefor be relocated or mirrored inside a remote BL\PL process. > 3) DL's can login to other DL's by dlID and dlPassword. Note dlPassword > is NOT blPassword. These are 2 seperate id+password tables. I can see a problem or conflict with the filesystem proposal here. A change made to a network by a second user, during the time when the first user is working on the network (and has not saved his changes), is a Bad Thing. I proposed that the whole volume or network be locked by the first user who mounts it. This is what all multi-user OSes do to an extent (maybe files are locked rather than whole volumes). And I see it as the simplest way to prevent the problem. But it means you just can't have DL's share a network. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 20:44:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] overall Message-ID: <38F2757D.7B28F6F6@geoserve.net> Overall, we'll have... 3 types of storage (1) Source (2) Network (3) Workspace 3 types authentication (1) Access to source (2) Access to network (3) Access to workspace (handled by UI) 2 types of connections/requests (1) Opening of network (mounting of volume) (2) Execution of source Correct? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 10 20:56:00 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] Re: overall References: <38F2757D.7B28F6F6@geoserve.net> Message-ID: <38F27820.A6A81A35@geoserve.net> Maybe make it all 3's: 3 types of storage (1) Source (2) Network (3) Workspace (handled by UI/DL) 3 types authentication (1) Access to source (2) Access to network (3) Access to workspace (handled by UI/DL) 3 types of connections/requests (1) Execution of source (2) Opening of network (mounting of volume) (3) Joining a session (handled by UI/DL) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue Apr 11 01:42:22 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] VSH Security model References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> <38EF0722.71DC4559@casema.net> <38EF90AF.A9276ECB@geoserve.net> <38F16619.E3147BB7@casema.net> <38F272B3.2686531E@geoserve.net> Message-ID: <38F2BB3E.A1E7CAC@casema.net> > > > 2) DL, Definition layer, coordination engine for scheduling UI's and > > partial sharing of structure data. Logs into the BL. > > 3) BL, Bropkering layer, engine for handling subnets, authentication of > > DL's and parsing to the PL. Wraps application plugins. > > 4) PL, Processing layer, holds the nodes, wraps (terminal?) applications > > and performs nodes processing. > > What actually holds the 'structure data' and manages the direct manipulation > of it? > Thinking the PL (overflow) hold all structures that come out the UI\DL. The BL holds a subset of this information needed for real life operation, like inet locations and encryption keys. The BL will define this information by applying static logic. > > > Authentication system: > > 0) Localhost has running VSH core, cq a BL\PL process. > > 1) UI's spawn a new DL. > > 2) DL's login to BL by their dlID and blPassword. > > 2a) The 1st DL loggin into a BL becomes the root DL and has the ability > > to authorize other DL's to log into the BL. (AddDL();) > > 2b) All subnets created by a DL are marked by the idDL and have the same > > login ability (or: idDL+blPassword) as their parent. Subnets can > > therefor be relocated or mirrored inside a remote BL\PL process. > > 3) DL's can login to other DL's by dlID and dlPassword. Note dlPassword > > is NOT blPassword. These are 2 seperate id+password tables. > > I can see a problem or conflict with the filesystem proposal here. A change > made to a network by a second user, during the time when the first user is > working on the network (and has not saved his changes), is a Bad Thing. Ic. We need some locking system. I'll think about it (too). > > > I proposed that the whole volume or network be locked by the first user who > mounts it. This is what all multi-user OSes do to an extent (maybe files are > locked rather than whole volumes). And I see it as the simplest way to > prevent the problem. But it means you just can't have DL's share a network. > I though this DL's sharing it's nodes with another DL is something that Loci would have gotten? Also I'll think about distributed filesystem proposal, when I understand it i'll give my views on it. From jarl at casema.net Tue Apr 11 01:44:08 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] overall References: <38F2757D.7B28F6F6@geoserve.net> Message-ID: <38F2BBA8.2E7E1BC0@casema.net> > Overall, we'll have... > > 3 types of storage > (1) Source > (2) Network > (3) Workspace > > 3 types authentication > (1) Access to source > (2) Access to network > (3) Access to workspace (handled by UI) This one is new to me :) How does this work? > > > 2 types of connections/requests > (1) Opening of network (mounting of volume) > (2) Execution of source > The rest seem ok, but again: I first have to grasp this distrubuted FS proposal. bye, jarl From jarl at casema.net Tue Apr 11 05:13:56 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] distributed filesystem proposal References: <38F25037.FE50BD78@geoserve.net> Message-ID: <38F2ECD4.1DDCC71A@casema.net> > > Comments please. Put it online :) I'll probably have some detaillistic comments later on when we need to technically implement it all, but in theory it's fine to me. So the cetral server gets 2 funtions: 1- exporting VSH instances locations so they can find each other. 2- supplying public nodes\subnets\networks that are somehow 'good'. bye, jarl From bizzaro at geoserve.net Tue Apr 11 09:47:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] VSH Security model References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> <38EF0722.71DC4559@casema.net> <38EF90AF.A9276ECB@geoserve.net> <38F16619.E3147BB7@casema.net> <38F272B3.2686531E@geoserve.net> <38F2BB3E.A1E7CAC@casema.net> Message-ID: <38F32D0C.86CB975B@geoserve.net> jarl van katwijk wrote: > > Thinking the PL (overflow) hold all structures that come out the UI\DL. The BL > holds a subset of this information needed for real life operation, like inet > locations and encryption keys. The BL will define this information by applying > static logic. I'm a bit confused about how and why PL (Overflow) would hold the structure of a distributed network of Overflow instances. Overflow should hold its own network structures, and the structures of Overflow instances should be held...in the BL or DL? No? > I though this DL's sharing it's nodes with another DL is something that Loci would > have gotten? I think there is some similarity between your idea for DL-sharing and Loci's plan for the UI's/DL's to 'share a session'. Brad, you are familiar with both ideas. Could we be talking about the same thing here? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 11 10:00:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] overall References: <38F2757D.7B28F6F6@geoserve.net> <38F2BBA8.2E7E1BC0@casema.net> Message-ID: <38F32FF6.BA1D41A9@geoserve.net> jarl van katwijk wrote: > > > 3 types authentication > > (1) Access to source > > (2) Access to network > > (3) Access to workspace (handled by UI) > > This one is new to me :) > How does this work? As I mentioned in my last e-mail, this is a Loci plan to allow mulitple UI's to 'share a session' (also mentioned in your security model). What we figured is you would have to connect a new UI at the very start of a session (so that the new UI is in sync with the others). And for security purposes, the new UI would have to log into the session. I think this is very similar to your plan for DL's to share access, but session sharing avoids the problem created by our need to lock volumes/networks. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 11 10:14:43 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] distributed filesystem proposal References: <38F25037.FE50BD78@geoserve.net> <38F2ECD4.1DDCC71A@casema.net> Message-ID: <38F33353.26C804CF@geoserve.net> Jarl van Katwijk wrote: > > So the cetral server gets 2 funtions: Okay, but since every copy of vsh will have the same filesystem, there will be no 'central Napster-like server' that all XML MUST pass through. The only REQUIREMENT for communication is when a volume/network is mounted/opened across the Internet (also the 'naming service' mentioned below). In such as case, the remote host needs to be kept up to date on changes. > 1- exporting VSH instances locations so they can find each other. This is Brad's 'naming service', which gives the location of DL's (vsh instances) and needs to be in one location on the Internet. This is the only 'central server' we really need. > 2- supplying public nodes\subnets\networks that are somehow 'good'. Ummmm. We can set up one big server with lots of networks and nodes available, and I plan on doing just that. But every copy of vsh will be able to do the same. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue Apr 11 09:13:15 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] VSH Security model References: <200004071107.HAA53566@archa10.cc.uga.edu> <38EE7646.D74E4733@geoserve.net> <38EE6C18.4D5135BF@casema.net> <38EE8405.F64F8E52@geoserve.net> <38EF0722.71DC4559@casema.net> <38EF90AF.A9276ECB@geoserve.net> <38F16619.E3147BB7@casema.net> <38F272B3.2686531E@geoserve.net> <38F2BB3E.A1E7CAC@casema.net> <38F32D0C.86CB975B@geoserve.net> Message-ID: <38F324EB.32BB122E@casema.net> > > I'm a bit confused about how and why PL (Overflow) would hold the structure of > a distributed network of Overflow instances. Overflow should hold its own > network structures, and the structures of Overflow instances should be > held...in the BL or DL? No? BL. > > > > I though this DL's sharing it's nodes with another DL is something that Loci would > > have gotten? > > I think there is some similarity between your idea for DL-sharing and Loci's > plan for the UI's/DL's to 'share a session'. Brad, you are familiar with both > ideas. Could we be talking about the same thing here? Yep, we are, this aint my idear, it's originally yours, translated to me by brad :) -- Math problems? Call 1-800-[(10x)(ln(13e))]-[sin(xy)/2.362x] From bizzaro at geoserve.net Tue Apr 11 12:52:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:45 2006 Subject: [Pipet Devel] thoughts on UI->DL communication Message-ID: <38F3584C.4084EB51@geoserve.net> Brad, Jarl and I were all talking about UI->DL communication over chat. I want to summarize my own thoughts. First, the VSH plan for the UI->DL parts and the communication between them, is to re-use Loci's Front->Middle parts and communication. So, VSH Loci ------ ------ UI->DL == Front->Middle But Loci's Front->Middle parts and communication are also very similar in design to VSH's DL->BL parts and communication. Both Front->Middle and DL->BL... * Act like client->server * Pass XML * Need authentication to connect * Can connect across a network So, I see a lot of duplication between UI->DL and DL->BL in the current plan that need not be there. Jarl suggested that VSH use 1 UI per DL. This makes DL a client rather than a server and eliminates much of the duplication mentioned above. But I wonder, if there is only 1 UI per DL, why do they need to be separate? Could they both be in Python? I think there are several advantages: (1) Speed: Direct Python communication rather than socket (2) Less processes running: 1 processes rather than 2 (3) Unified code base (4) One less authentication system needed (recall we would need 3) (5) Elimination of sockets: keep corba as the only protocol (6) No XML management (reading and writing) between the two I would propose that both the UI and the DL be combined into one Python code base, and have the UI (in particular, the Gnome UI) be a module library for the DL to import. This UI library would have a well defined API with events, etc. But Brad pointed out that there would be (at least) 2 problems: (1) There would be a lot of rewriting to do, which would make Brad very unhappy. I'm not suggesting that we re-integrate the two parts. I think the separation is good, because the use of the UI as a library would require a separate anyway. And as far as work goes, I can do it myself. (2) Other UI's would have to be made in Python. Actually, there are 2 ways we can make UI's in other languages: (a) The whole UI->DL part can be written in another language and use CORBA to communicate with the BL. (b) Write a UI part in Python that can communicate with non-Python UI's, using a language-neutral protocol like CORBA. My argument for doing it now is this: IT WILL BE A LOT HARDER LATER ON WHEN THE UI->DL PROTOCOL BECOMES BETTER DEVELOPED! Comments? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 11 13:28:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> Message-ID: <38F360B8.8BCE49B4@geoserve.net> I also think the BL needs to handle the management of permanent network/volume storage. The DL/UI will handle the temporary loading of networks/volumes into a workspace. Coordinated control of a network/volume by multiple UI's/DL's will be handled the following way: UI UI | | \|/ \|/ DL _____\ DL / | \|/ root DL | \|/ BL As per Jarl's suggestion. So, there really is only DL->DL authentication, correct? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue Apr 11 14:27:31 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> Message-ID: <38F36E93.97665BCB@casema.net> > Brad, Jarl and I were all talking about UI->DL communication over chat. I > want to summarize my own thoughts. > > First, the VSH plan for the UI->DL parts and the communication between them, > is to re-use Loci's Front->Middle parts and communication. So, > > VSH Loci > ------ ------ > UI->DL == Front->Middle > > But Loci's Front->Middle parts and communication are also very similar in > design to VSH's DL->BL parts and communication. Both Front->Middle and > DL->BL... > > * Act like client->server > * Pass XML > * Need authentication to connect > * Can connect across a network > > So, I see a lot of duplication between UI->DL and DL->BL in the current plan > that need not be there. > > Jarl suggested that VSH use 1 UI per DL. This makes DL a client rather than a > server and eliminates much of the duplication mentioned above. > Not really, I've been my lungs out, lot, and came up with this: -Make the dl be a 'wrapper' for UI's, not an extension. I'm saying this: let the DL make programming new UI's easy. Various scripting and new GUI can be developped fast that way. I dont know WHAT the DL should be doing, that's probably a question that Brad can answer best, but programming the BL corba and implementing the DL api every time again when somebody makes an UI\DL (read: single application) seems like a dull thing to do. And there will be numberous features to code that will make the DL a nice part of the VSH project. > (1) Speed: Direct Python communication rather than socket > (2) Less processes running: 1 processes rather than 2 > (3) Unified code base > (4) One less authentication system needed (recall we would need 3) > (5) Elimination of sockets: keep corba as the only protocol > (6) No XML management (reading and writing) between the two Good points you brought up here Jeff, but not as good as mine :-) About (4), we'll only need 2 authentication systems, the UI wont log into the DL, it will link\fork it, the DL will log into the BL or another DL. If this login does not succeed both the UI\DL will be rejected. Maybe Brad and you can figure someting out that 'fixes' (5) & (6), if needed. I dont see (1), (2) and (3) as big problems. > > (1) There would be a lot of rewriting to do, which would make Brad > very unhappy. We definitly wont have that, I cant stand blood :) > > I'm not suggesting that we re-integrate the two parts. I think the separation > is good, because the use of the UI as a library would require a separate > anyway. And as far as work goes, I can do it myself. Library, sounds good > > > (2) Other UI's would have to be made in Python. They have to? There's no way the DL code can be compiled as binairy?? (Python -> C -> binairy) Stick to the sockets otherwise. > (a) The whole UI->DL part can be written in another language > and use CORBA to communicate with the BL. Aaiiks. The result would be very nice though. > > (b) Write a UI part in Python that can communicate with non-Python > UI's, using a language-neutral protocol like CORBA. Nah.. please dont! Use corba for UI->DL communication instead if sockets aint good enough. bye, jarl From jarl at casema.net Tue Apr 11 14:40:19 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> Message-ID: <38F37193.ADD617B8@casema.net> "J.W. Bizzaro" wrote: > I also think the BL needs to handle the management of permanent network/volume > storage. No problem. I think I hardly need to change anything about the storage, only need to realize the retreival code. GMS currently stores all data that passed its net to disk. (or gms naming: 'historyIO') This is kinda rough, but in principal it's what you need. > > > The DL/UI will handle the temporary loading of networks/volumes into a > workspace. Yep, by doing so reducing processing load. > > > UI UI > | | > \ | / \ | / > rootDL DL > | | > \ | / \ | / > BL > > > As per Jarl's suggestion. So, there really is only DL->DL authentication, > correct? No, arf, this is my suggestion: 1) 2) 3) UI UI UI | | | \ | / \ | / \ | / rootDL DL <--- DL | | \ | / \ | / BROKERING LAYER 1- rootDL log AUTOMATICALLY into the BL, 2- this rootDL can grant other DL's access to the BL, 3- every DL can deside to grant other DL access to ITS OWN nodes. (but maybe the rootDL shouldn't be able to do (3)? ) Clear? bye, jarl From bizzaro at geoserve.net Tue Apr 11 16:26:38 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F36E93.97665BCB@casema.net> Message-ID: <38F38A7E.FE84B24D@geoserve.net> jarl van katwijk wrote: > > -Make the dl be a 'wrapper' for UI's, not an extension. > I'm saying this: let the DL make programming new UI's easy. So, how would the DL 'wrap' a UI? Isn't this the same as making the UI a library? > Various scripting and new GUI can be developped fast that way. I dont know WHAT > the DL should be doing, that's probably a question that Brad can answer best, > but > programming the BL corba and implementing the DL api every time again when > somebody makes an UI\DL (read: single application) seems like a dull thing to do. But which is easier: making the DL in C and making language bindings to the DL, or making a new corba idl? > About (4), we'll only need 2 authentication systems, the UI wont log into the DL, The original Loci plan was to have a UI log into the 'Middle'. I think both Brad and I were expecting this to happen in VSH between UI and DL. > > (2) Other UI's would have to be made in Python. > > They have to? There's no way the DL code can be compiled as binairy?? > (Python -> C -> binairy) I was suggesting to pull out Brad's upper teeth. Now you're suggesting to pull out his lower teeth ;-) Making the DL in C is an option, and one I did not think of. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 11 16:30:28 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> Message-ID: <38F38B64.4EC4A617@geoserve.net> jarl van katwijk wrote: > > No, arf, this is my suggestion: > > 1) 2) 3) > > UI UI UI > | | | > \ | / \ | / \ | / > rootDL DL <--- DL > | | > \ | / \ | / > BROKERING LAYER > > 1- rootDL log AUTOMATICALLY into the BL, > 2- this rootDL can grant other DL's access to the BL, > 3- every DL can deside to grant other DL access to ITS OWN nodes. I thought that is what I said. > (but maybe the rootDL shouldn't be able to do (3)? ) The rootDL has to grant access to another DL. That's the only way DL's connect to the BL: through the rootDL, correct? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 11 19:52:13 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] articles on napster and gnutella Message-ID: <38F3BAAD.53BE5564@geoserve.net> Interesting: Gnutella has no central location. It's modeled after the way the Internet itself is connected: One person starts the software, connecting directly to another person who is running the service, who is connected to a third, and so on, with as many individual links as there are people running the software. http://news.cnet.com/news/0-1005-200-1676249.html http://news.cnet.com/news/0-1005-200-1581232.html Jeff From jarl at casema.net Wed Apr 12 01:27:45 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F36E93.97665BCB@casema.net> <38F38A7E.FE84B24D@geoserve.net> Message-ID: <38F40951.301F1A30@casema.net> > > So, how would the DL 'wrap' a UI? Isn't this the same as making the UI a > library? > Yes. > > But which is easier: making the DL in C and making language bindings to the > DL, or making a new corba idl? For us, or for future 3th party developpers? > > > > They have to? There's no way the DL code can be compiled as binairy?? > > (Python -> C -> binairy) > > I was suggesting to pull out Brad's upper teeth. Now you're suggesting to > pull out his lower teeth ;-) > > Making the DL in C is an option, and one I did not think of. Not making, but compiling, automaocally, like the pascal-2-C convertors. From jarl at casema.net Wed Apr 12 01:30:06 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> Message-ID: <38F409DE.BBAF9500@casema.net> > > 1- rootDL log AUTOMATICALLY into the BL, > > 2- this rootDL can grant other DL's access to the BL, > > 3- every DL can deside to grant other DL access to ITS OWN nodes. > > I thought that is what I said. Not really :) > > The rootDL has to grant access to another DL. That's the only way DL's > connect to the BL: through the rootDL, correct? No, the rootDL calls the autorize() function inside the BL, passes a new dlID and password, so that this other dl can login to the BL. From jarl at casema.net Wed Apr 12 01:54:49 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] interesting project References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F409DE.BBAF9500@casema.net> Message-ID: <38F40FA9.35249E82@casema.net> http://www.cs.cornell.edu/Info/Projects/Ensemble/index.html bye, jarl From jarl at casema.net Fri Apr 14 07:12:34 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> Message-ID: <38F6FD21.7276455B@casema.net> Hi all, seems we got almost drowned in the proposals and idears we came up with, so I my plan is to do VSH in phases, and the 1st one is the build a pilot. Made up with the sourcecode we currently got , enhanched with code that's absolutely neccesairy to have the layers communicate. so, we'll - stick to what we got, no rewrites - work localhost oriented, so no remote host connections - dont implement all the complex structures we want to have VSH 1.0 have - dont spend much time into cleaning\bugfixing\memleak removal\ ect. When the pilot is up and running, we'll start posting proposals again. Everybody (exspecially Jeff, Jean and Brad) OK with this? Please please dont turn this post into a flame :-) jarl From jean-marc.valin at hermes.usherb.ca Fri Apr 14 08:46:14 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> Message-ID: <38F71316.C213CB06@hermes.usherb.ca> > seems we got almost drowned in the proposals and idears we came up with, > so I my plan is to do VSH in phases, and the 1st one is the build a pilot. > Made > up with the sourcecode we currently got , enhanched with code that's > absolutely > neccesairy to have the layers communicate. > > so, we'll > - stick to what we got, no rewrites > - work localhost oriented, so no remote host connections > - dont implement all the complex structures we want to have VSH 1.0 have > - dont spend much time into cleaning\bugfixing\memleak removal\ ect. > > When the pilot is up and running, we'll start posting proposals again. > > Everybody (exspecially Jeff, Jean and Brad) OK with this? > Please please dont turn this post into a flame :-) I've got no problem with that (BTW, my name is Jean-Marc, not Jean)! For the next two weeks, I won't have much time to code, but I can help people use the Overflow libraries. I don't think Overflow itself will need much changes for this first phase anyway. BTW, anyone still have problems compiling/running Overflow (except Brad on FreeBSD - how are things going Brad?) Also, I guess we should all agree on a version of libXML. They broke source compatibility twice after the release I'm using (1.7.3). For 1.8 it was minor, but they changed all the names in version 2. Jean-Marc From jean-marc.valin at hermes.usherb.ca Fri Apr 14 08:50:52 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> Message-ID: <38F7142C.EB3A3ED7@hermes.usherb.ca> I think it's time to start thinking (not flaming ;-) ) about licenses to use. What will be GPL, what will be LGPL? Also, I was thinking about a Linux-like exception to the GPL for overflow, allowing "binary-only" plugins for new nodes and types. Any comment? Let's try not to have a flame war, but it's always simpler to discuss licenses right from the beginning. Jean-Marc From jarl at casema.net Fri Apr 14 11:26:08 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> Message-ID: <38F73890.AC865ED9@casema.net> > What will be GPL, what will be LGPL? Also, I was thinking about a Linux-like > exception to the GPL for overflow, allowing "binary-only" plugins for new nodes > and types. > Maybe let every project deside between BSD, GPL or LGPL. Or do we also want to have a licence for the VSH combination? bye, jarl -- http://sunsite.auc.dk/gms From jarl at casema.net Fri Apr 14 11:32:10 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F71316.C213CB06@hermes.usherb.ca> Message-ID: <38F739FA.88B30705@casema.net> > > I've got no problem with that (BTW, my name is Jean-Marc, not Jean)! Hehe, ok, sorry > For the > next two weeks, I won't have much time to code, but I can help people use the > Overflow libraries. I don't think Overflow itself will need much changes for > this first phase anyway. > > BTW, anyone still have problems compiling/running Overflow (except Brad on > FreeBSD - how are things going Brad?) I gave my linux a refresh, also installed gcc 2.9.5, but still got this comilation error: ---cut--- make[2]: Entering directory `/usr/install/interesing/Overflow-0.1.0/audio_blocks/src' /bin/sh ../libtool --mode=compile c++ -DLINUX=1 -DPROTOTYPES=1 -DHAVE_LIBM=1 -I. -I. -I../../data-flow/include -I../include -I/usr/local/include -g -O2 -c FFT.cc rm -f .libs/FFT.lo c++ -DLINUX=1 -DPROTOTYPES=1 -DHAVE_LIBM=1 -I. -I. -I../../data-flow/include -I../include -I/usr/local/include -g -O2 -c -fPIC -DPIC FFT.cc -o .libs/FFT.lo FFT.cc: In method `void FFT::calculate(int, int, Buffer &)': FFT.cc:66: passing `float *' as argument 2 of `rfftw_one(fftw_plan_struct *, fftw_real *, fftw_real *)' ---cut--- Did I install gcc wrong, or is this something else? > > > Also, I guess we should all agree on a version of libXML. They broke source > compatibility twice after the release I'm using (1.7.3). For 1.8 it was minor, > but they changed all the names in version 2. Ic, what do you think about stability\features, which version is best? And which version would requier as less work as possible? bye From jean-marc.valin at hermes.usherb.ca Fri Apr 14 13:32:52 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F71316.C213CB06@hermes.usherb.ca> <38F739FA.88B30705@casema.net> Message-ID: <38F75644.D166C120@hermes.usherb.ca> > I gave my linux a refresh, also installed gcc 2.9.5, but still got this > comilation error: > ---cut--- > make[2]: Entering directory > `/usr/install/interesing/Overflow-0.1.0/audio_blocks/src' > /bin/sh ../libtool --mode=compile c++ -DLINUX=1 -DPROTOTYPES=1 -DHAVE_LIBM=1 -I. > -I. -I../../data-flow/include -I../include -I/usr/local/include -g -O2 -c > FFT.cc > rm -f .libs/FFT.lo > c++ -DLINUX=1 -DPROTOTYPES=1 -DHAVE_LIBM=1 -I. -I. -I../../data-flow/include > -I../include -I/usr/local/include -g -O2 -c -fPIC -DPIC FFT.cc -o .libs/FFT.lo > FFT.cc: In method `void FFT::calculate(int, int, Buffer &)': > FFT.cc:66: passing `float *' as argument 2 of `rfftw_one(fftw_plan_struct *, > fftw_real *, fftw_real *)' > ---cut--- > Did I install gcc wrong, or is this something else? It's not a gcc problem (you have 2.95.x, right?), it's about FFTW, it sould be configured with --enable-flow otherwise, the routines expect (double *) instead of (float *). This is a bit annoying, but there isn't much I can do about it. BTW, for those who have problems with some .cc files, note that most of them can be remove and the link will still work. For instance, if you remove FFT.cc from the build, the FFT node will just not appear in the menu. > > > > > > Also, I guess we should all agree on a version of libXML. They broke source > > compatibility twice after the release I'm using (1.7.3). For 1.8 it was minor, > > but they changed all the names in version 2. > > Ic, what do you think about stability\features, which version is best? > And which version would requier as less work as possible? Don't know. Anybody's using XML yet? I guess we could have the code handle all 1.x releases... and then decide when we switch to 2.x (I don't think distros have shipped with 2.x yet). Jean-Marc From bizzaro at geoserve.net Fri Apr 14 17:12:27 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> Message-ID: <38F789BB.23DAA322@geoserve.net> Jean-Marc Valin wrote: > > I think it's time to start thinking (not flaming ;-) ) about licenses to use. > What will be GPL, what will be LGPL? Also, I was thinking about a Linux-like > exception to the GPL for overflow, allowing "binary-only" plugins for new nodes > and types. I'm glad you brought this up, since I have been thinking about this issue. Loci is licensed under the LGPL (Lesser GPL), and NOT the ordinary GPL. This was done for a very specific reason: The GPL does NOT allow linking from non-GPL programs, but the LGPL DOES. Most GNU libraries are in fact LGPL: Gtk, Gnome, ORBit, etc. The orginal plan for Loci was much like our current plan for VSH: Make a system that allows unrelated programs communicate across the Internet. And since we would probably like non-GPL programs to be included in this system, I think the LGPL would be best. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 14 17:21:27 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> Message-ID: <38F78BD7.D1AFC6C0@geoserve.net> Jarl van Katwijk wrote: > > so, we'll > - stick to what we got, no rewrites Meaning, don't rewrite UI->DL ;-) Don't worry, I won't flame you. > - work localhost oriented, so no remote host connections That's the simplest way to start. > - dont implement all the complex structures we want to have VSH 1.0 have > - dont spend much time into cleaning\bugfixing\memleak removal\ ect. > > When the pilot is up and running, we'll start posting proposals again. > > Everybody (exspecially Jeff, Jean and Brad) OK with this? > Please please dont turn this post into a flame :-) Yeah, I'm okay with it. I'm not in a big rush to see the implementation of a final design. If there's one thing to learn from Loci, it's that 'good things come to those who wait' :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 14 17:22:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F71316.C213CB06@hermes.usherb.ca> Message-ID: <38F78C30.D1FCE146@geoserve.net> Jean-Marc Valin wrote: > > Also, I guess we should all agree on a version of libXML. They broke source > compatibility twice after the release I'm using (1.7.3). For 1.8 it was minor, > but they changed all the names in version 2. I don't see any reason to continue with obsolete versions. We should follow Gnome's progression to Gnome 1.2 and 2.0. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Fri Apr 14 17:15:46 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> Message-ID: <38F78A82.C5C67FE5@geoserve.net> jarl van katwijk wrote: > > Maybe let every project deside between BSD, GPL or LGPL. *GASP* BSD???!!! ;-) > Or do we also want to have a licence for the VSH combination? Well, my impression is that we're working toward a unified system, distributed in a single tarball. I think we need to agree on one license. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Fri Apr 14 17:01:00 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F78BD7.D1AFC6C0@geoserve.net> Message-ID: <38F7870C.2E08E13@casema.net> > Yeah, I'm okay with it. I'm not in a big rush to see the implementation of a > final design. If there's one thing to learn from Loci, it's that 'good things > come to those who wait' :-) ok, so you, Jean-Mark and I are ok. We only need to persuade Brad into not rewriting the DL into some wierd language every few days again. hope we got something running within a few weeks. I'm currently cleaning up the GMS code so version 0.4.0 hits the public ftp within a few hours. After that I will focus on getting the DL->BL corba alife and linking the Overflow libs to gms. bye, jarl From jarl at casema.net Fri Apr 14 17:02:20 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> Message-ID: <38F7875C.68E59888@casema.net> > > > > Or do we also want to have a licence for the VSH combination? > > Well, my impression is that we're working toward a unified system, distributed > in a single tarball. I think we need to agree on one license. > ok, LGPL. From jarl at casema.net Fri Apr 14 20:11:02 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] new gms References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F71316.C213CB06@hermes.usherb.ca> <38F78C30.D1FCE146@geoserve.net> Message-ID: <38F7B396.5E6E211@casema.net> hi testers, put the pre7 online, http://sunsite.auc.dk/gms/gms-0.4.0pre7.tar.gz when there're no compilation probs it will become the final. bye From chapmanb at arches.uga.edu Sat Apr 15 12:20:36 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] libXML WAS thoughts on UI->DL communication Message-ID: <200004151623.MAA89518@archa10.cc.uga.edu> > Jean-Marc Valin wrote: >> >> Also, I guess we should all agree on a version of libXML. They broke source >> compatibility twice after the release I'm using (1.7.3). For 1.8 it was > minor, >> but they changed all the names in version 2. Jarl wrote: > Ic, what do you think about stability\features, which version is best? > And which version would requier as less work as possible? Jeff wrote: > I don't see any reason to continue with obsolete versions. We should follow > Gnome's progression to Gnome 1.2 and 2.0. I don't really know anything about libXML (since I'm using python xml tools) but I read somewhere there was a SAX interface for libXML (...looking for it...okay, here is tutorial on it -> http://developer.gnome.org/doc/tutorials/xml-sax/xml-sax.html). Could you guys use that interface? It seems like the SAX parsing interface should remain stable (that is the point of SAX, I guess) so then you wouldn't have to worry about the interfaces changes to libXML. This is basically what I do in python, and then I don't have to worry about underlying changes in the parsers. Or is it the SAX interface that is changing? (in which case I'm completely off base and should be smacked around :) Brad From chapmanb at arches.uga.edu Sat Apr 15 12:26:17 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:46 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication Message-ID: <200004151628.MAA75838@archa11.cc.uga.edu> Jarl wrote: > ok, so you, Jean-Mark and I are ok. > We only need to persuade Brad into not rewriting the DL into some > wierd language every few days again. Damn, and I was just about ready to release my Lisp version of the dl :-) That plan sounds great to me, Jarl. I think once we have a basic working version of everything, then it will easier to proceed and move foward with other things we would like to implement. I think our basic overall plan is sound, and we'll just have to go forward with that see how things turn out :-) Brad From bizzaro at geoserve.net Sat Apr 15 13:21:29 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <200004151628.MAA75838@archa11.cc.uga.edu> Message-ID: <38F8A519.A5DC181C@geoserve.net> Brad Chapman wrote: > > Damn, and I was just about ready to release my Lisp version of the dl > :-) THE LESSER-KNOWN PROGRAMMING LANGUAGES #12: LITHP This otherwise unremarkable language is distinguished by the absence of an "S" in its character set; users must substitute "TH". LITHP is said to be useful in protheththing lithtth. (fortune) ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Sat Apr 15 14:01:55 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] libXML WAS thoughts on UI->DL communication References: <200004151623.MAA89518@archa10.cc.uga.edu> Message-ID: <38F8AE93.E93EE90C@hermes.usherb.ca> > I don't really know anything about libXML (since I'm using python > xml tools) but I read somewhere there was a SAX interface for libXML > (...looking for it...okay, here is tutorial on it -> > http://developer.gnome.org/doc/tutorials/xml-sax/xml-sax.html). Could > you guys use that interface? It seems like the SAX parsing interface > should remain stable (that is the point of SAX, I guess) so then you > wouldn't have to worry about the interfaces changes to libXML. > This is basically what I do in python, and then I don't have to > worry about underlying changes in the parsers. Or is it the SAX > interface that is changing? (in which case I'm completely off base and > should be smacked around :) It's not that much a maintenance issue, then just portability. From what I understand the changes from libXML 1 to 2 are things like struct member names (like "childs" replaced by "children"). The upgrade could be made by "sed". It's just something that's annoying. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Mon Apr 17 17:04:13 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> Message-ID: <38FB7C4D.72373460@geoserve.net> jarl van katwijk wrote: > > > Well, my impression is that we're working toward a unified system, distributed > > in a single tarball. I think we need to agree on one license. > > ok, LGPL. So, Jarl and I agree on LGPL for everything. Jean-Marc? It may actually be most important for the PL (Overflow library) to be LGPL, since it will be the layer to interface with foreign applications. Brad, Gary? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Mon Apr 17 18:22:44 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> Message-ID: <38FB8EB4.66E34626@hermes.usherb.ca> "J.W. Bizzaro" a ?crit : > > jarl van katwijk wrote: > > > > > Well, my impression is that we're working toward a unified system, distributed > > > in a single tarball. I think we need to agree on one license. > > > > ok, LGPL. > > So, Jarl and I agree on LGPL for everything. Jean-Marc? It may actually be > most important for the PL (Overflow library) to be LGPL, since it will be the > layer to interface with foreign applications. LGPL is OK for me. Though I propose the same license modification as in Linux: allow linking with closed-source binaries. Overflow can use foreign nodes and types compiled in a shared library. This is forbidden by the (L)GPL, unless it is explicitly allowed, as for the Linux kernel (which allow closed-source drivers). Anyone thinks this is bad? Jean-Marc From bizzaro at geoserve.net Mon Apr 17 18:42:20 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> Message-ID: <38FB934C.183B3935@geoserve.net> Jean-Marc Valin wrote: > > LGPL is OK for me. Though I propose the same license modification as in Linux: > allow linking with closed-source binaries. ... > Anyone thinks this is bad? That's fine with me. I like everything about the GPL, except for the restriction on linking to/from closed-source binaries. That's why I prefer the LGPL. > Overflow can use foreign nodes and > types compiled in a shared library. This is forbidden by the (L)GPL, unless it > is explicitly allowed, as for the Linux kernel (which allow closed-source > drivers). I thought the Linux kernel was GPL, not LGPL. The LGPL already provides an exception for linking to/from closed-source binaries. Can you post the passage in the LGPL or GPL where you have to 'explicitly allow' closed-source linking? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Mon Apr 17 19:31:16 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FB934C.183B3935@geoserve.net> Message-ID: <38FB9EC4.8D38F067@hermes.usherb.ca> "J.W. Bizzaro" a ?crit : > > Jean-Marc Valin wrote: > > > > LGPL is OK for me. Though I propose the same license modification as in Linux: > > allow linking with closed-source binaries. > ... > > Anyone thinks this is bad? > > That's fine with me. I like everything about the GPL, except for the > restriction on linking to/from closed-source binaries. That's why I prefer > the LGPL. > > > Overflow can use foreign nodes and > > types compiled in a shared library. This is forbidden by the (L)GPL, unless it > > is explicitly allowed, as for the Linux kernel (which allow closed-source > > drivers). > > I thought the Linux kernel was GPL, not LGPL. > > The LGPL already provides an exception for linking to/from closed-source > binaries. Can you post the passage in the LGPL or GPL where you have to > 'explicitly allow' closed-source linking? There are two very different issues here. The LGPL allows a closed-cource program to link with the Overflow libraries. However, neither the GPL, nor the LGPL allows to link the program/library with a closed-source library. This means that even is Overflow is LGPL (for the libraries) and GPL (for the program), you couldn't link it with a closed-source library. This is the same reason why KDE was at one point "illegal", since it was linking against a closed-source library, Qt. Because of that issue with the LGPL, Linus explicitly "modified" the GPL to allow closed-source drivers. Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From bizzaro at geoserve.net Mon Apr 17 22:56:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FB934C.183B3935@geoserve.net> <38FB9EC4.8D38F067@hermes.usherb.ca> Message-ID: <38FBCEC8.B1483F37@geoserve.net> Jean-Marc Valin wrote: > > There are two very different issues here. The LGPL allows a closed-cource > program to link with the Overflow libraries. However, neither the GPL, nor the > LGPL allows to link the program/library with a closed-source library. This means > that even is Overflow is LGPL (for the libraries) and GPL (for the program), you > couldn't link it with a closed-source library. I understand that there is a difference between linking FROM your program and linking TO your program. The LGPL allows the latter, but the GPL does not. > This is the same reason why KDE > was at one point "illegal", since it was linking against a closed-source > library, Qt. It would be illegal to INCORPORATE a GPL program into a non-GPL program. If linking KDE to QT were illegal, then every Motif, Java, etc. program licensed under the GPL would be as well. I think the issue with KDE was that, using a commercial library, it was not as open as it could be. The (L)GPL does not actually distinguish between 'open-source' and 'non-open-source' software. It only distinguishes between GPL and non-GPL software. So, even though Mozilla is open-source, it would be illegal to incorporate a GPL program into it. > Because of that issue with the LGPL, Linus explicitly "modified" the GPL to > allow closed-source drivers. I attached the license for the Linux kernel to this e-mail. It is the GPL, not the LGPL. Linus has a small note at the top about the kernel being different from the Linux applications that may use it. I don't see any modification to the license. Can you point it out to me? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ -------------- next part -------------- NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Linus Torvalds ---------------------------------------- GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) 19yy This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. , 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License. From jarl at casema.net Tue Apr 18 01:41:43 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> Message-ID: <38FBF597.4B90C215@casema.net> > LGPL is OK for me. Though I propose the same license modification as in Linux: > allow linking with closed-source binaries. Overflow can use foreign nodes and > types compiled in a shared library. This is forbidden by the (L)GPL, unless it > is explicitly allowed, as for the Linux kernel (which allow closed-source > drivers). Anyone thinks this is bad? > No , better as LGPL. What's this licence version called? From bizzaro at geoserve.net Tue Apr 18 09:12:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> Message-ID: <38FC5F47.9909BBA4@geoserve.net> jarl van katwijk wrote: > > No , better as LGPL. What's this licence version called? What is the LGPL called? 'Lesser General Public License' Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue Apr 18 08:43:46 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> Message-ID: <38FC5881.7065A6D7@casema.net> "J.W. Bizzaro" wrote: > jarl van katwijk wrote: > > > > No , better as LGPL. What's this licence version called? > > What is the LGPL called? 'Lesser General Public License' :)) NO, this OTHER licence. From bizzaro at geoserve.net Tue Apr 18 10:11:08 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> <38FC5881.7065A6D7@casema.net> Message-ID: <38FC6CFC.FFDE8602@geoserve.net> Jarl van Katwijk wrote: > > NO, this OTHER licence. Do you mean the modified GPL that Jean-Marc was talking about? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue Apr 18 09:44:57 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> <38FC5881.7065A6D7@casema.net> <38FC6CFC.FFDE8602@geoserve.net> Message-ID: <38FC66D9.89DF2746@casema.net> "J.W. Bizzaro" wrote: > Jarl van Katwijk wrote: > > > > NO, this OTHER licence. > > Do you mean the modified GPL that Jean-Marc was talking about? > Yes, the one that makes it possible to have programs wrapped\linked that are of any type of licence. bye, jarl From bizzaro at geoserve.net Tue Apr 18 11:26:34 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> <38FC5881.7065A6D7@casema.net> <38FC6CFC.FFDE8602@geoserve.net> <38FC66D Message-ID: <38FC7EAA.9F8505DE@geoserve.net> 9.89DF2746@casema.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jarl van Katwijk wrote: > > > Yes, the one that makes it possible to have programs > wrapped\linked that > are of any type of licence. The way I see it, the LGPL allows the 'linking' of the LGPL program to a non-GPL program (the ordinary GPL does not allow it). Unfortunately, the LGPL does not define very well what is meant by 'linking' :-( I know that 'linking' does not mean 'incorporating'. We should define these in our own license: 'Incorporating' means to combine code bases to the extent that the programs are packaged and compiled together: They essentially become one program. 'Linking' is the connection of a SPECIFIC program/library to VSh to form a path of communication that is REQUIRED for either VSh or the program/library to function. IPC between VSh and another executable program is NOT considered 'linking', since either can function without the other. It makes sense that making a connection between Netscape Navigator and Apache is not the 'linking' mentioned and restricted by the GPL, doesn't it? The GPL only addresses certain types of linking. I think this is what Linus Torvalds is saying in his note atop the Linux license: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". If we add to the LGPL, definitions of 'linking' and 'incorporating' like the ones I gave, we should be covered for connecting non-GPL programs and libraries to VSh. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Tue Apr 18 12:16:49 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> <38FC5881.7065A6D7@casema.net> <38FC6CFC.FFDE8602@geoserve.net> <38FC66D <38FC7EAA.9F8505DE@geoserve.net> Message-ID: <38FC8A71.E53A29D9@hermes.usherb.ca> > It makes sense that making a connection between Netscape Navigator and Apache > is not the 'linking' mentioned and restricted by the GPL, doesn't it? The GPL > only addresses certain types of linking. I think this is what Linus Torvalds > is saying in his note atop the Linux license: > > NOTE! This copyright does *not* cover user programs that use kernel > services by normal system calls - this is merely considered normal use > of the kernel, and does *not* fall under the heading of "derived work". This is not the part of the Linux license I was referring to (and unfortunatly, I cannot find it now). It Linux was using the "pure GPL", then it would mean that every part of it would have to be GPL compatible. Also, the (L)GPL states that all the code, including what you link (in the sense of library linking) to, has to be GPL-compatible. If Linux was "pure GPL" then it would not allow you to "link" Linux with a proprietary driver. I know Linus made an explicit exception that allow that "softens" the GPL and allow you to use proprietary drivers, as long as they are a module, and (I'm not sure about this one) the driver doesn't require a change in the kernel. BTW, the reason Debian didn't ship with KDE until Qt was "open-sourced" was that KDE didn't comply with the GPL by linking to Qt. Anyway, I think we all agree on the important: allow people to develop proprietary Overflow modules and distribute them as .so only. Jean-Marc From bizzaro at geoserve.net Tue Apr 18 16:52:07 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> <38FC5881.7065A6D7@casema.net> <38FC6CFC.FFDE8602@geoserve.net> <38FC66D <38FC7EAA.9F8505DE@geoserve.net> <38FC8A71.E53A29D9@hermes.usherb.ca> Message-ID: <38FCCAF7.A61F7558@geoserve.net> Jean-Marc Valin wrote: > > This is not the part of the Linux license I was referring to (and unfortunatly, > I cannot find it now). Well, let me know if you come across it. > It Linux was using the "pure GPL", then it would mean > that every part of it would have to be GPL compatible. You need to distinguish between the Linux kernel and the GNU/Linux OS. Every part of the kernel needs to be GPL, true. But, every part of the OS does NOT have to be GPL. This is because the applications that run in the OS are not 'linking' to the kernel by the GPL's definition of 'linking'. This is what Linus means when he says that other applications are not a 'derivative work' of the kernel. > Also, the (L)GPL states > that all the code, including what you link (in the sense of library linking) to, > has to be GPL-compatible. The ordinary GPL states that, not the LGPL. That's the whole reason for the LGPL: to allow linking. > If Linux was "pure GPL" then it would not allow you to > "link" Linux with a proprietary driver. I know Linus made an explicit exception > that allow that "softens" the GPL and allow you to use proprietary drivers, as > long as they are a module, Right, they are not 'incorporated' into the kernel. > and (I'm not sure about this one) the driver doesn't > require a change in the kernel. BTW, the reason Debian didn't ship with KDE > until Qt was "open-sourced" was that KDE didn't comply with the GPL by linking > to Qt. Actually, if Debian shipped KDE, they would have to ship the commercial Qt too. And it was *Qt* that violated the Debian definition of free software ;-) But I do recall a number of people questioning the legality of linking the GPL'd KDE with the commercial Qt. It goes to show that the definition of 'linking' is not very clear in the (L)GPL. > Anyway, I think we all agree on the important: allow people to develop > proprietary Overflow modules and distribute them as .so only. So far, you, Jarl and I have stated we would like some modified version of the LGPL. But we haven't heard from Brad and Dominic, both of whom contributed code. Every author needs to agree on this. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 18 17:21:05 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> <38FC5881.7065A6D7@casema.net> <38FC6CFC.FFDE8602@geoserve.net> <38FC66D Message-ID: <38FCD1C1.4342B09@geoserve.net> <38FC7EAA.9F8505DE@geoserve.net> <38FC8A71.E53A29D9@hermes.usherb.ca> <38FCCAF7.A61F7558@geoserve.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "J.W. Bizzaro" wrote: > > So far, you, Jarl and I have stated we would like some modified version of the > LGPL. I don't know if the LGPL needs to be modified. The GPL would, since it restricts linking. But the LGPL allows it. Please show me in the LGPL where we'd have a problem using a closed-source, binary program or library with the LGPL. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Tue Apr 18 17:24:31 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License Message-ID: <200004182126.RAA56884@archa11.cc.uga.edu> > So far, you, Jarl and I have stated we would like some modified version of > the > LGPL. But we haven't heard from Brad and Dominic, both of whom contributed > code. Every author needs to agree on this. Sorry, I don't know anything about licenses, so I'm just your posts trying to learn some. What you all are saying sounds fine to me--I guess I only care about two things: 1. Anyone who wants to use Loci/Vsh can do so freely (although if they *really want* to pay us, I won't be arguing :-) 2. No one can take Vsh (or a slightly modified version of it) and sell it. I think this is what everyone is saying, but I really don't know enough about licenses to know what does it best, and you guys seem to be doing fine at figuring it out :-) Brad From jarl at casema.net Tue Apr 18 18:47:46 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] License References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F6FD21.7276455B@casema.net> <38F7142C.EB3A3ED7@hermes.usherb.ca> <38F73890.AC865ED9@casema.net> <38F78A82.C5C67FE5@geoserve.net> <38F7875C.68E59888@casema.net> <38FB7C4D.72373460@geoserve.net> <38FB8EB4.66E34626@hermes.usherb.ca> <38FBF597.4B90C215@casema.net> <38FC5F47.9909BBA4@geoserve.net> <38FC5881.7065A6D7@casema.net> <38FC6CFC.FFDE8602@geoserve.net> <38FC66D <38FC7EAA.9F8505DE@geoserve.net> <38FC8A71.E53A29D9@hermes.usherb.ca> Message-ID: <38FCE612.6F7A03A3@casema.net> > Anyway, I think we all agree on the important: allow people to develop > proprietary Overflow modules and distribute them as .so only. fine to me. As long as everthing can be plugged in. And the VSH source is gpl'ed From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:27 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21030@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] Overview > --- Bodytext delivered in separate SMS messages --- (1/10) > What I would like to try and hash out is a plan for a CORBA > interface with the GMS. I think for a rough outline it would need the > following pa (2/10) rts: > > 0. Initializing a connection between the "middle"/GUI and the > processing engine. > > 1. A way to pass structured information (in the form of (3/10) XML or DOM) to > the processing engine, so that it can take this XML and use it to > build it a pull network or neural net system. > > 2. A method for r (4/10) equesting a list of programs/libraries registered > with the processing engine. I think the "middle" should keep XML > descriptions of these separate fr (5/10) om the processing engine, so this way > we can keep the messaging objects light weight (ie. they don't need > any knowledge of the description or other (6/10) info about a program--just > how to run it and get stuff back from it). This way the "middle" can > also keep the XML files for programs organized into (7/10) directories of > similar programs, so they will be easy to find for the user. However, > before giving a GUI access to a program representation, it will (8/10) need > to confirm with the middle that the > > 3. Methods for querying the middle to determine the "status" of a > process. > > 4. Methods for returnin (9/10) g the generated info (ie. for viewing) to the > GUI. > > Others? This is just some stuff off the top of my head. I would like > to keep it simple at fir (10/10) st, if possible, but still keep all the > functionality that GMS and Overflow currently have. This will be a good starting point. > I would be happy to > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:34 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:47 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21068@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: brad chapman : [Pipet Devel] Initial idl proposal > --- Bodytext delivered in separate SMS messages --- (1/10) Hello all; Based on the broad design I mentioned yesterday for communicating between a small middle (part of the GUI) and the "data processing engine" o (2/10) f 'vsh', I drew up an idl as a starting point for this communication. This definately need a lot of work and if the first idl I've ever written, so I ca (3/10) n use lots of comments and criticisms, but this will be something to build off of so we can get things going. I look forward to hearing comments! Brad / (4/10) / gui2dp.idl // // IDL for dealing with communication between the GUI (buffered by a small // middle) and the data processing engine. /** * Organization (5/10) of modules. * vsh: The overall module (the name can change when we decide on a formal * name). * gui2dp: idl for communication between the GUI a (6/10) nd the data processing * engine. * */ module vsh { module gui2dp { // ##### exceptions /** * Requested Id is already being used for another gu (7/10) i. */ exception IdInUse {}; /** * Id number used for requested operation was not found in the list of * current gui ids being served by the data process (8/10) or. */ exception IdNotFound{}; /** * The information for a node is not yet available because the process * has not completed. */ exception InfoNotAvaila (9/10) ble{}; // ##### structs and typedefs /** * A sequence/list of strings. Useful for returning info like a list of * program ids for available programs. */ (10/10) typedef sequence stringList; // ##### interfaces /** * Functions for dealing with a front to middle connection. */ interface Connection { /** > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:35 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21075@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: brad chapman : [Pipet Devel] Project Design (fwd) > --- Bodytext delivered in separate SMS messages --- (1/10) Hey all; This is from a discussion Jarl and I were having, and I thought it was really relevant to everyone. I like this plan for integrating everythin (2/10) g--whadda you all think? Brad - Forwarded message ---------- Date: Thu, 23 Mar 2000 19:45:42 +0100 From: jarl van katwijk To: Brad Cha (3/10) pman Subject: Project Design > > Well, the only think I worry about is that Overflow probably doesn't > want to be "absorbed" (4/10) into GMS and would like to be able to work > independently. Couldn't the authentication go in a > "processing/pre-processing engine" that then directs s (5/10) tuff to either > GMS or Overflow? I know the Overflow people dont want their code integrated, but I'm saying to this: Loci based GUI | -> Communication (6/10) SAME AS current Loci's GUI, only enhanced | with various extra gms & overflow features. \/ Scripts -----> 'Brad's Interperter' :-) | (7/10) -> Translates scripts\GUI calls to 'gms api+', which will be a reviced | gms api + the current Overflow api. So gms will select what calls | are to be h (8/10) andled and which ones are to be passed to overflow \/ Remote Env.---> GMS based broker --> Remote Environment | -> This communicatio (9/10) n is THE SAME as subnet-subnet comm. | AND as Oveflow-GUI comm. GMS will emulate that api \/ Local Env.----> Overflow based processor ---> Local Environ (10/10) ment SO Gms will be adjusted to 'speak' to overflow, overflow stays the same as it is, only restricted to local operation. And the Loci GUI will stay th > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:25 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21024@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] gui protocol revisited > --- Bodytext delivered in separate SMS messages --- (1/7) > > I thought that we could keep both the streaming XML dialog *and* > CORBA, but just in two different places in the program. My idea was > that we could (2/7) keep the small middle that we have in Loci right now to > communiate with the GUI front via the streaming XML dialog you > describe. A kinda 'script inte (3/7) rpeter'.. very good idear > > move through a work flow diagram in an even "smarter" way (ie. based > on the fastest way to implement it) which is what Jar (4/7) l seems to be > proposing for GMS's with the neural net and genetic algorithms > processor. Yes. The GAP will also try to apply new succesfull structures (5/7) that are generated elsewhere. > Does this make any sense? I think this gives us a lot of reuse of > code, while maintaing the streaming XML that Jeff (6/7) digs and the > CORBA/API interfaces of Overflow and GMS. OK to me. It would also be a very good point for you to start working on. __ pipet-devel maillist (7/7) - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:02 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21192@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] Project Design (fwd) > --- Bodytext delivered in separate SMS messages --- (1/10) Brad Chapman wrote: > > SO Gms will be adjusted to 'speak' to overflow, overflow stays the same > as it is, only restricted to local > operation. And th (2/10) e Loci GUI will stay the same. > > Every body happy? I don't know if this is relevant to this thread, but I would like the GUI to have Overflow instance (3/10) s contained in separate nodes. So, Overflow networks are VSH subnets. And, Overflow 'workspaces' are displayed in VSH 'windowlets'. This really fits (4/10) in with the 'Overflow networks are local' idea, and it's what I was thinking of when I drew up those flowcharts. > Currently gms processes one data-even (5/10) t at a time, so a data-chunk > passed the whole structure before the next is prosessed. This will > have to change to better 'all at once' processing. (6/10) Just so that Loci gets its 2 cents in on this design discussion, I was thinking Loci would use a 'processor centric' approach to the problem. That is, (7/10) whatever processes or modifies data in a network is first to be called. This isn't any different from the 'pull' approach when you think about it, but t (8/10) here are some other considerations that should be given to this special class of nodes. Afterall, we're dealing with data, and the modification of thos (9/10) e data affects the whole system. Jeff - +----------------------------------+ | J.W. Bizzaro | | | | (10/10) http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:12 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21228@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] 3/1 and 1/3 > --- Bodytext delivered in separate SMS messages --- (1/9) jarl van katwijk wrote: > > Example: It's absolutely no problem to me that Overflow can connect to > non-local subnets\nodes, but for the collaboration's (2/9) sake Overflow should > have support to disable this. > Ex2: GMS will continue to support it's own GUI, I like it for testing. > > My only constraint is th (3/9) at I want to be able to use Overflow as a stand alone > > application. At the very LEAST, a collaboration should mean that the respective projects (Loci/G (4/9) MS/Oveflow) don't continue development in such a way as to incorporate incompatibilities with VSH. If you're not excited about VSH right now, then fine, (5/9) maybe you will be later. But you need to... (1) Tell us what features you'll be adding to your program (2) Consider whether or not features will work in (6/9) the VSH system (3) Be prepared to change your program to incorporate a VSH feature Cheers. Jeff - +----------------------------------+ | J.W. Bi (7/9) zzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.O (8/9) RG | | The Open Lab | | | | http://bioinformatics.org/ | +------------------------------ (9/9) ----+ __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:30 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21285@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] 3/1 and 1/3 > --- Bodytext delivered in separate SMS messages --- (1/6) > At the very LEAST, a collaboration should mean that the respective projects > (Loci/GMS/Oveflow) don't continue development in such a way as to incorpor (2/6) ate > incompatibilities with VSH. If you're not excited about VSH right now, then > fine, maybe you will be later. But you need to... > > (1) Tell us (3/6) what features you'll be adding to your program > (2) Consider whether or not features will work in the VSH system > (3) Be prepared to change your pro (4/6) gram to incorporate a VSH feature > OK to me. It seems gms will get the most changes, but that's no problem. I'm only saying the coming time the VSH proje (5/6) ct will contains 3 types of code: 1) general code, 2) collaborate code & 3) standalone code I think these dont need any further explanation. bye, jarl __ (6/6) pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:02 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21196@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] gui protocol revisited > --- Bodytext delivered in separate SMS messages --- (1/10) Brad Chapman wrote: > > I thought that we could keep both the streaming XML dialog *and* > CORBA, but just in two different places in the program. My id (2/10) ea was > that we could keep the small middle that we have in Loci right now to > communiate with the GUI front via the streaming XML dialog you > descri (3/10) be. Okay, if you like that. And I guess Jarl likes it too. > This small middle could then also implement the CORBA interfaces > to pass the informa (4/10) tion created in the GUI (as a work flow diagram) > into the "processing" portion of the program. It would make sense to > pass this as DOM or XML, since (5/10) it seems like a nice structured way to > store the data (and since Overflow already uses it to feed its "pull" > networking system). I think that event (6/10) ually the processing part could > move through a work flow diagram in an even "smarter" way (ie. based > on the fastest way to implement it) which is wh (7/10) at Jarl seems to be > proposing for GMS's with the neural net and genetic algorithms > processor. Here it seens to makes sense to start with what we hav (8/10) e > (the Overflow pull system) and move into something more robust as > things move along. I'm a little confused about this 'processing part of the prog (9/10) ram'. Is this something GMS or Overflow has now? Is it something you'll have to write? Also Brad, recall how Loci was going to use an XML database (XD (10/10) BM) to store the workflow diagram (network and subnetworks). How does this relate to the 'processing' part? Perhaps you can explain this to the others > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:57 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21160@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] Re: Ideas for network distributed objects > --- Bodytext delivered in separate SMS messages --- (1/10) jarl van katwijk wrote: > > > Jarl, what do you think about Loci's idea of using XML for GUI > > representations? > > Hmm? Please explain, I can't pinpo (2/10) int what you're trying to say. Here's the short and simple: The user sets the parameters for nodes via some kind of interface. The interface is describ (3/10) ed via an XML akin to the HTML forms generated by CGI programs. It's much quicker than other ways to transfer G/UIs. Plus, the XML can be combined to g (4/10) enerate more elaborate GUIs. Here is a Gtk GUI in GLADE XML as an example of how complex GUIs can be made with XML: GtkWindow < (5/10) name>window1 window1 GTK_WINDOW_TOPLEVEL GTK_WIN_POS_NONE True True False GtkFixed fixed1 GtkButton (7/10) button1 32 16 112 40 True Notice the heirarchy of widgets. NOW THIS IS IMPORTANT: The heirarchy of nodes in a subnet, plus the XML descriptions of their interfaces, can be us (9/10) ed to arrange widgets and construct a GUI! This is all in the Loci archives where we discussed 'composited GUIs' and 'constructing the command-line'. I (10/10) 'll certainly be talking more about this later, as it is a major design feature of Loci. Cheers. Jeff - +----------------------------------+ | > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:58 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21171@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jean-marc valin : Re: [Pipet Devel] 3/1 and 1/3 > --- Bodytext delivered in separate SMS messages --- (1/10) > At the very LEAST, a collaboration should mean that the respective projects > (Loci/GMS/Oveflow) don't continue development in such a way as to incorp (2/10) orate > incompatibilities with VSH. If you're not excited about VSH right now, then > fine, maybe you will be later. But you need to... > > (1) Tell (3/10) us what features you'll be adding to your program > (2) Consider whether or not features will work in the VSH system > (3) Be prepared to change yo (4/10) ur program to incorporate a VSH feature That's no problem... Overflow is built in a very modular way. All the functionality is built into nodes (C++ cla (5/10) sses). If you don't like some of them, you just don't use them, but they don't interfere. If you "rm" a library you don't want, things will still work ( (6/10) without recompiling). The same for the Overflow types (like neural nets, vector quantizers, ...). As for supporting VSH, every new feature will simply b (7/10) e a new node in Overflow. About the architecture... what about this: Everything that's done locally (including running other exceutables) is handled by (8/10) 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" (9/10) 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 (10/10) assumed to be "network-able". 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 t > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:50 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21133@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] gui protocol revisited > --- Bodytext delivered in separate SMS messages --- (1/5) "J.W. Bizzaro" wrote: > > I consider the interfaces/fronts to be completely > 'dumb', acting only on the requests of user and core. This is how it works: (2/5) USER: Hey VSH, do this for me! GUI: Duh...Hey Core, can I do this? CORE: Yeah, go ahead Gui. GUI: Duh...Okee dokee. Jeff - +------------------------ (3/5) ----------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | (4/5) | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | (5/5) +----------------------------------+ __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:41 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21086@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jean-marc valin : Re: [Pipet Devel] Project Design (fwd) > --- Bodytext delivered in separate SMS messages --- (1/10) > > Well, the only think I worry about is that Overflow probably doesn't > > want to be "absorbed" into GMS and would like to be able to work > > indepe (2/10) ndently. Couldn't the authentication go in a > > "processing/pre-processing engine" that then directs stuff to either > > GMS or Overflow? > > I know th (3/10) e Overflow people dont want their code integrated, but I'm > saying > to this: Depends on what you mean by integrated. 90% of Overflow is just a library (4/10) . You're actually probably better use that library in GMS instead of the executables. If you call that integrating Overflow in GMS, well fine, If you wa (5/10) nt to wrap the executable, fine too (though I don't think it's the best way). If you want to take some chunks of code and put that in GMS... have fun(go (6/10) od luck)! My only constraint is that I want to be able to use Overflow as a stand alone application. > > Loci based (7/10) GUI > | > -> Communication SAME AS current Loci's GUI, only enhanced > (8/10) | > with various extra gms & overflow features. > \/ > Scripts -----> 'Brad's Interperter' :-) Speaki (9/10) ng of interpreter... I was planning on implementing an Overflow node that uses the Octave interpreter (actually, only the octave library)... > (10/10) | -> > Translates scripts\GUI calls to 'gms api+', which will be a reviced > > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:46 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21112@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] node-to-node communication: you can have it 3 ways! > --- Bodytext delivered in separate SMS messages --- (1/6) jarl van katwijk wrote: > > SO the basis design for a collaboration-pilot is clear to me, I want to know if > everybody else is also OK and we can start d (2/6) iscussing the implementation of > this pilot. > Every project please come to a conclussion.. I agree with Brad that Loci is pretty much ready for integrat (3/6) ion, although there may be some more development in the meantime that does not conflict with the merger. Jeff - +----------------------------------+ | (4/6) J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BI (5/6) OINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +---------------- (6/6) ------------------+ __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:44 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21103@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : [Pipet Devel] 3/1 and 1/3 > --- Bodytext delivered in separate SMS messages --- (1/7) > > Depends on what you mean by integrated. 90% of Overflow is just a library. > You're actually probably better use that library in GMS instead of the > (2/7) executables. If you call that integrating Overflow in GMS, well fine, If you > want to wrap the executable, fine too (though I don't think it's the best w (3/7) ay). > If you want to take some chunks of code and put that in GMS... have fun(good > luck)! Using the libraries is by far the best methode. I dont want a (4/7) physical intergration, but there has got to come a general design: which member does what? Example: It's absolutely no problem to me that Overflow can co (5/7) nnect to non-local subnets\nodes, but for the collaboration's sake Overflow should have support to disable this. Ex2: GMS will continue to support it's ow (6/7) n GUI, I like it for testing. All the flowcharts describe the collaborated situation. > > My only constraint is that I want to be able to use Overflow as (7/7) a stand alone > application. Agreed. __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:49 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21127@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] 3/1 and 1/3 > --- Bodytext delivered in separate SMS messages --- (1/6) "J.W. Bizzaro" wrote: > > (1) Tell us what features you'll be adding to your program > (2) Consider whether or not features will work in the VSH syste (2/6) m > (3) Be prepared to change your program to incorporate a VSH feature Of course, you can always fork your project and create two: one for VSH and one (3/6) for your own experimental purposes. Jeff - +----------------------------------+ | J.W. Bizzaro | | | (4/6) | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | (5/6) | | http://bioinformatics.org/ | +----------------------------------+ __ pipet-devel maillist - pipet-devel@bioinform (6/6) atics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:45 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21108@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : [Pipet Devel] Project Design > --- Bodytext delivered in separate SMS messages --- (1/3) Hi, Could somebody collect all the design proposals and wishes and stuff and put them on the VSH page. Sometimes I'm saying\reading things twice :) I coul (2/3) d do this , but somebody else probably write better english as I do.. bye, jarl __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinfor (3/3) matics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:48 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21120@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] Overview > --- Bodytext delivered in separate SMS messages --- (1/8) jarl van katwijk wrote: > > C is more suitable for the 'inbetween' functionality gms will get in the > VSH design. It has more 'hackish' functionality. > (2/8) But i'm also quite happy about Overflow & GUI being OOP because it makes > sence to build those OOP. I'm happy about the Overflow code staying C++. It's (3/8) a great choice being OO and binary executable. Python/Gnome is probably the best choice for the GUI too. > OK, then I will communicate with Brad about th (4/8) e details.. any dessision > that will infuence design etc will be posted pubically ofcourse. Keep as much on the list as possible :-) > K, maybe it's logi (5/8) cal that you'll do this 'in-between' code that talks to > the gui and the core? Yep. Jeff - +----------------------------------+ | J.W. Bizzaro (6/8) | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG (7/8) | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ (8/8) __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From bizzaro at geoserve.net Thu Apr 20 01:56:16 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Email to SMS gateway Message-ID: <38FE9C00.588FCBF7@geoserve.net> What was that all about? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu Apr 20 02:08:41 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Email to SMS gateway References: <38FE9C00.588FCBF7@geoserve.net> Message-ID: <38FE9EE9.8DE65BE1@casema.net> "J.W. Bizzaro" wrote: > What was that all about? Sorry, my 'mistake'. Enabled the email of my phone, had fethmail forward my current pop3 box. But those suckers reply each and every mail. I'm gonna complain to them today. bye, jarl From bizzaro at geoserve.net Mon Apr 24 09:25:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F36E93.97665BCB@casema.net> <38F38A7E.FE84B24D@geoserve.net> <38F40951.301F1A30@casema.net> Message-ID: <39044B59.546B6C09@geoserve.net> *yawn* It's pretty quiet. I'll reply to a couple old messages. jarl van katwijk wrote: > > > Making the DL in C is an option, and one I did not think of. > > Not making, but compiling, automaocally, like the pascal-2-C convertors. Oh, there is a Python-2-C converter, but I wouldn't use it. There is so much 'overhead' involved that the simplest Python script converts into a massive C file. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Mon Apr 24 08:25:17 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F36E93.97665BCB@casema.net> <38F38A7E.FE84B24D@geoserve.net> <38F40951.301F1A30@casema.net> <39044B59.546B6C09@geoserve.net> Message-ID: <39043D2C.59756A2@casema.net> > > > > Not making, but compiling, automaocally, like the pascal-2-C convertors. > > Oh, there is a Python-2-C converter, but I wouldn't use it. There is so much > 'overhead' involved that the simplest Python script converts into a massive C > file. Any URL? From bizzaro at geoserve.net Mon Apr 24 09:31:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] Re: thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F360B8.8BCE49B4@geoserve.net> <38F37193.ADD617B8@casema.net> <38F38B64.4EC4A617@geoserve.net> <38F409DE.BBAF9500@casema.net> Message-ID: <39044CC1.A3063EC3@geoserve.net> jarl van katwijk wrote: > > > The rootDL has to grant access to another DL. That's the only way DL's > > connect to the BL: through the rootDL, correct? > > No, the rootDL calls the autorize() function inside the BL, passes a new dlID > and password, so that this other dl can login to the BL. I see. Concerning the 'filesystem', a DL->BL session will lock one volume/network for itself. A DL->DL->BL session (as Jarl thought up) would require the two DL's to be synchronized somehow. Either they will have to be initialized (started) together, or one DL will have to update itself to the current state of the other DL. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 24 09:34:13 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] thoughts on UI->DL communication References: <38F3584C.4084EB51@geoserve.net> <38F36E93.97665BCB@casema.net> <38F38A7E.FE84B24D@geoserve.net> <38F40951.301F1A30@casema.net> <39044B59.546B6C09@geoserve.net> <39043D2C.59756A2@casema.net> Message-ID: <39044D55.AD121B76@geoserve.net> jarl van katwijk wrote: > > > Oh, there is a Python-2-C converter, but I wouldn't use it. There is so much > > 'overhead' involved that the simplest Python script converts into a massive C > > file. > > Any URL? Sorry about that. Here is the URL: http://lima.mudlib.org/~rassilon/p2c/ Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 24 09:49:02 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:48 2006 Subject: [Pipet Devel] summary for web page and announcements Message-ID: <390450CE.9E591753@geoserve.net> I'd like to post the summary to the web page. We left off with a BL summary by Jarl and one of the DL by Brad. But the DL summary got quite a few comments that led to additions and modifications. At this point, there is no simple summary for the DL. Perhaps Brad can put some thoughts into 2-4 short paragraphs. I personally need to make a summary for the UI. Also, Jean-Marc or Jarl needs to make a summary for the PL. Remember to keep the summaries short. This is not meant to be a journal article on the subject, just something for the main web page. And after we get that put up, I would like to make some announcements about the collaboration. I know that we don't have a working system yet, but I can mention that Overflow, GMS and Loci have merged. And I can mention what our plans are. This is very important so that people know we are here, and so that no-one tries to make a VSh of their own ;-) Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Mon Apr 24 09:54:23 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] summary for web page and announcements References: <390450CE.9E591753@geoserve.net> Message-ID: <3904520F.CD3C1378@geoserve.net> "J.W. Bizzaro" wrote: > > At this point, there is no simple summary for the DL. Perhaps Brad can put > some thoughts into 2-4 short paragraphs. Brad, could you point out in your summary what it is that the DL does that would be too difficult to reproduce for each UI? IOW, why does the DL have to be separate from the UI (besides the amount of work already put into separating them ;-))? This is not just for me; other people will ask the same thing. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon Apr 24 10:49:56 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] summary for web page and announcements Message-ID: <200004241452.KAA97312@archa11.cc.uga.edu> >> At this point, there is no simple summary for the DL. Perhaps Brad can put >> some thoughts into 2-4 short paragraphs. Cointenly. I'll be working on docs for the dl to describe the structure of it and will work on this as well. Okay, now Brad is going to get serious for a moment, so get very nervous :-). Jeff wrote: > Brad, could you point out in your summary what it is that the DL does that > would be too difficult to reproduce for each UI? IOW, why does the DL have > to > be separate from the UI (besides the amount of work already put into > separating them ;-))? This is not just for me; other people will ask the > same > thing. Jeff, To answer your question, I'd like to include this little snippet from a discussion we had on the Loci list but two months ago (Feb 22) about implementing the streaming xml dialog for communication between the middle and the front: ---------------------------------------------------------------------- ---- I wrote: > Also, I wonder why we need this kind of dialog--why can't we just > talk back and forth in python? It seems like even with a web > interface, you'll have to have some kind of language generating the > tags and recieving the responses, and why not make that python? Jeff responded: Because... (1) We want to allow front-ends to be made in languages other than Python. (2) We want to be able to use standard IPC protocols like HTTP. (3) We want a 'transcript' that can be read back by Loci and humans. ---------------------------------------------------------------------- ---- The front to middle dialog was implemented based on your design plan. I am not much of a designer and am but a coding monkey to implement your master plans. I implemented the protocol and separation because: a. It was your design plan. b. I think it is a good plan, and think the separation between front and middle will reduce a lot of coding redundancy in implementing new front ends (in addition to allowing front ends to be made in other languages). I will admit that I am *less than thrilled* to see you continually pushing for the exact opposite design plan less than a month after the implementation of your initial design plan was _finally_ finsihed. I do not mind revamping code to support new and better ideas, but do not enjoy throwing away hundreds of lines of code because of widly oscillating design plans. This is quite frustrating for me, since I am working on this project in my "spare" time and would at least like to at least have my efforts be recognized as useful for moving forward with completion of this project. By contrast, it seems like the code I contribute is being considered dispensible and the time I spend on things is considered unimportant. IMO, part of making design plans should be considering what is already present and moving forward with it, especially in the case where your "workers" are volunteers. I really love the Loci/Vsh project and want to help it move forward but I do not enjoy wasting my time. In the future I would either like to see a little more respect for contributed code in making design decisions, or a kind e-mail letting me know that I code like a first grader and should take my idiot code and shove it where the sun don't shine. At least than I can go back to my previous job digging big holes and then filling them in. Sorry for the tirade, I'm going to go take my medication now :-) Brad From bizzaro at geoserve.net Mon Apr 24 12:05:56 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] summary for web page and announcements References: <200004241452.KAA97312@archa11.cc.uga.edu> Message-ID: <390470E4.D0F4A36D@geoserve.net> Brad, DESIGN changes should never be looked at as an insult to the CODER. If the design needs to be changed, it's the fault of the DESIGNER. I never said there is something wrong with your code for Loci's middle or that you 'code like a first grader'. In fact, it has been very valuable for the evolution and progression of the project. Maybe we need to have a Brad Appreciation Day ;-) As one of the designers of this project, I recognize a problem in the new design. The problem was not there a couple months ago when I implored you to make an XML-based, streaming dialog that runs through a socket. (YES, I KNOW THAT YOU WANTED A CORBA API, AND I SAID NO.) You insisted on CORBA everywhere, and Tada! that's the way it seems we're now going. But, why are we going that way? Why have things changed? BECAUSE NOW WE ARE TRYING TO GLUE GMS AND OVERFLOW TO LOCI, AND BECAUSE CORBA, NOT SOCKETS, WAS CHOSEN AS THE GLUE! (Sorry about my own tirade there.) What is the problem? Loci front -> middle HAS NOT BECOME VSh front -> middle and I simply think it should have. IOW, my original design for a front -> middle API (and all of the code you wrote) was set aside, and the same sort of thing was made in CORBA for a VSh front -> middle API. IMO, THEY'RE SUPPOSED TO BE THE SAME THING. What we have now is... [Loci front -> middle] -> VSh middle VSh front -> middle (DL -> BL) could have been your XML-based command stream through a socket, as I originally designed and wanted for Loci. I could have continued to say no to CORBA, but the interest and experience both you and Jarl have with it, was overwhelming. I am making consessions to democracy for the sake of the collaboration. So, maybe it was a mistake to have said no to CORBA in the first place. Maybe it was a mistake to have split the front and middle of Loci. Had I listened to you, we wouldn't be in this situation. My bad. But we're in this situation. All I can say is that if it bothers you, we'll keep the UI -> DL API. And we can all say it is Jeff's fault. We COULD also consider combining Loci's middle with the VSh BL (using C-Python bindings) and keep the front -> middle communication in sockets. But I won't make the mistake again of planning a major change in your code. I'll leave it up to you. What route should we take? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Mon Apr 24 15:07:18 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] summary for web page and announcements Message-ID: <200004241909.PAA177750@archa10.cc.uga.edu> > DESIGN changes should never be looked at as an insult to the CODER. If the > design needs to be changed, it's the fault of the DESIGNER. I never said > there is something wrong with your code for Loci's middle or that you 'code > like a first grader'. In fact, it has been very valuable for the evolution > and progression of the project. Maybe we need to have a Brad Appreciation > Day > ;-) Jeff, I'm not trying to place any kind of blame, and I don't need to be patted on the back to feel good about myself--all I am saying is that we should respect existing code when making design decisions. Previous changes have required changing code, which is fine, because things are not perfect. But tossing away code, as you are suggesting to do here, is just not smart. We already are sorely in need of programmers, and throwing away functional code is not the way to make best use of our time, or encourage new people to join on. I know that things change, but you have to understand how it would make you feel to have people talking about dumping something that you have put a lot of work into. In this case dumping code is the easiest decision to make, but not the best--we need to think up a solution which does not involve this. > As one of the designers of this project, I recognize a problem in the new > design. > What is the problem? > > Loci front -> middle > > HAS NOT BECOME > > VSh front -> middle > > and I simply think it should have. I disagree. GMS is not the middle we were talking about before--the dl is. The middle has/will have a lot of functionality that is not present in the bl/gms: 1. Representing a gui as xml in both temporary and permanent storage. 2. Communicating with non-program/library elements, such as the local filesystem and databases. 3. Converting the xml format used to represent and store info for the gui into a format that can be easily read by a processing engine. 4. Authenticating remote connections from other Vsh programs. Lumping this functionality into the front will make it *extremely unlikely* that anyone will ever bother to implement a different front end, as this is too much crap to deal with. Lumping this functionality into gms/overflow will make these programs bloated and make it difficult to do cool things like increase processing efficiency. The original design barely even took into account having a processing component since that was still waaaaaaay in the future. Thanks to Jarl we have that now, so we just need to modify the design to incorporate this. As far as I'm concerned we are dealing with more a point of view problem than an actual problem with the functional code. Can you point out specific problems in the current ui to dl communication which make it worth throwing out? > What we have now is... > > [Loci front -> middle] -> VSh middle What do the []s mean? I just see us as having: loci front -> loci middle -> gms So what? We are dealing with two totally separate apis, and the middle communicates with them. Dealing with a user interface is a serious pain, you have to take into account that the user can connect, disconnect, delete, add, and otherwise do whatever they want whenever the want. Thus the api for communicating with a ui is going to be inherently huge and messy. By contrast the api for communicating with the processing engine is nice and clean--give it some stuff to process, and get your results back out. Aaaah, so nice :) The current middle/dl will do the translation between the ui api and the processing api and hopefully allow both to function at their best. For a program with proposed multiple user interfaces (an excellent idea), you need something to translate between the uis and the processing layer, and this is what the dl does. > VSh front -> middle (DL -> BL) could have been your XML-based command stream > through a socket, as I originally designed and wanted for Loci. I could have > continued to say no to CORBA, but the interest and experience both you and > Jarl have with it, was overwhelming. I am making consessions to democracy > for > the sake of the collaboration. The actual communication protocol isn't very important, it is the api that is being represented. Take a look at the communication protocol for front to middle communication and the corba interface for dl to bl communication. I don't see any kind of duplication between the two and the dl is the code that is doing the translation. If we want to try and connect a ui directly with a processing engine, then we will either get a huge crazy interface for the processing engine to have to deal with, or a ui that just mimics calls directly to the processing engine. The Overflow gui is a great example of making direct processing to gui interface seen more natural. The gui is beautiful and (IMO) quite intuitive to use, but in its underlying design is still guiizing calls to functions. If you take a look at the menus they have tons of selections, all corresponding to individual functions/calls, and their xml design is set up to mimic a C program (as Jean-Marc was describing earlier). However, this seems like it will be hard to expand to include an arbitrary number of programs and be a "generalized" application wrapper. I think the dl can make this transition feasible (hopefully :). > But we're in this situation. All I can say is that if it bothers you, we'll > keep the UI -> DL API. And we can all say it is Jeff's fault. I just don't understand the horrendous consequences you seem to see if adding an extra communication layer. Maybe you could describe the specific problems you see. > We COULD also consider combining Loci's middle with the VSh BL (using > C-Python > bindings). This is no different than communicating through corba, it is just a different way to do it. CORBA is much more flexible since we can change the interface while we are doing things, while wrappers will make changing things a whole lot harder. > But I won't > make the mistake again of planning a major change in your code. I'll leave > it up to you. What route should we take? I wasn't saying that I want complete design control--I know that I am not a good designer, which is why I'm working on problems with other people. I just want design decisions to be made respecting working contributed code. Since we now have actual code, we can't afford to make designs as if everything is vaporware, and need to work around what we already have. I would say this even if it wasn't my own code that we are talking about :-) Brad From bizzaro at geoserve.net Tue Apr 25 01:35:50 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] the empire strikes back (was: summary for web page and announcements) References: <200004241909.PAA177750@archa10.cc.uga.edu> Message-ID: <39052EB6.DE09B34A@geoserve.net> Brad, This is the kind of explanation we need for the summary if we are to go forward with the extra communication layer. We have to be able to say WHY the DL should be separate from the UI. If people on this list don't understand why, you can bet that people visiting our web site won't understand. Honestly, I didn't understand your point of view and probably still don't. I only heard that I need to 'respect existing code'. But from my understanding, it was only the preservation of existing code that was determining the design. > Jeff, I'm not trying to place any kind of blame, and I don't need to > be patted on the back to feel good about myself--all I am saying is > that we should respect existing code when making design decisions. > Previous changes have required changing code, which is fine, because > things are not perfect. But tossing away code, as you are suggesting > to do here, is just not smart. I would never do such a thing without thought, but you keep characterizing my suggestion as being whimsical. I don't need to remind you how much GMS and Overflow code will be 'tossed away' for the collaborative. Jarl said that GMS will be radically changed, probably more so than any other program. And Overflow will become a library and lose its GUI (over 1,000 LOC's). GMS will also lose its GUI. So, what will Loci lose? I know, it's easy for me to say these things, since it's not my own code that is in question. > We already are sorely in need of > programmers, and throwing away functional code is not the way to make > best use of our time, or encourage new people to join on. EVEN IF WE DID CHANGE THE PROTOCOL OR API, I WOULDN'T DO IT NOW. There's too much else to be done. I was talking about the final state of VSh. > I know that > things change, but you have to understand how it would make you feel > to have people talking about dumping something that you have put a lot > of work into. Probably a lot like Jean-Marc and Jarl feel ;-) > In this case dumping code is the easiest decision to > make, but not the best--we need to think up a solution which does not > involve this. I think the best decision to make is the one that you feel most comfortable with. You can tell that I am a perfectionist. I tend to work and rework everything until I like what I've done. I personally want to feel right about the design of VSh, especially since this is something that has consumed and will continue to consume years of my life. But the same goes for everyone else. Do you feel right about your design decision, Brad? > I disagree. GMS is not the middle we were talking about before--the dl > is. The middle has/will have a lot of functionality that is not > present in the bl/gms: > > 1. Representing a gui as xml in both temporary and permanent storage. Isn't this kept with the node and network information/XML? > 2. Communicating with non-program/library elements, such as the local > filesystem and databases. What is to be kept in the local filesystem and databases? > 3. Converting the xml format used to represent and store info for the > gui into a format that can be easily read by a processing engine. Hmmm. I thought the PL's wrapping mechanism was going to do this, or maybe the BL. How much XML is stripped off before the BL and PL get the information? > 4. Authenticating remote connections from other Vsh programs. Yeah, but you and Jarl have plans for DL->BL authentication. Are you talking about this or a UI->DL authentication system? > Lumping this functionality into the front will make it *extremely > unlikely* that anyone will ever bother to implement a different front > end, as this is too much crap to deal with. Lumping this functionality > into gms/overflow will make these programs bloated and make it > difficult to do cool things like increase processing efficiency. But I'm not convinced that something so close to the front as the DL is should be manipulating the network structure and managing the filesystem. I see these as core operations. This is why I suggested the DL be part of the BL. > The original design barely even took into account having a > processing component since that was still waaaaaaay in the future. > Thanks to Jarl we have that now, so we just need to modify the design > to incorporate this. But the PL (Overflow) handles processing. Now you're saying Jarl's BL does. I'm very confused. > As far as I'm concerned we are dealing with more a point of view > problem than an actual problem with the functional code. Can you point > out specific problems in the current ui to dl communication which make > it worth throwing out? Because both UI->DL and DL->BL ... (1) Act like client->server (2) Pass XML (3) Need authentication to connect (4) Can connect across a network and because there would be numerous advantages to combining UI and DL: (5) Speed: Direct Python communication rather than socket (6) Less processes running: 1 process rather than 2 (7) Unified code base (8) One less authentication system needed (recall we would need 3) (9) Elimination of sockets: keep corba as the only protocol (10) No XML management (reading and writing) between the two > > What we have now is... > > > > [Loci front -> middle] -> VSh middle > > What do the []s mean? I just see us as having: [Loci front -> middle] == VSh front > loci front -> loci middle -> gms > > So what? We are dealing with two totally separate apis, and the > middle communicates with them. Dealing with a user interface is a > serious pain, you have to take into account that the user can > connect, disconnect, delete, add, and otherwise do whatever they want > whenever the want. Thus the api for communicating with a ui is going > to be inherently huge and messy. But from what I understand, and I think Jarl agrees with me, one DL represents one user: 1UI:1DL and xDL:1BL. So, then DL->BL already handles issues with the user. > By contrast the api for communicating with the processing engine > is nice and clean--give it some stuff to process, and get your results > back out. Aaaah, so nice :) Ummm. What are you calling the 'processing engine'? BL+PL or just PL? > The current middle/dl will do the translation between the ui api > and the processing api and hopefully allow both to function at their > best. For a program with proposed multiple user interfaces (an > excellent idea), you need something to translate between the uis and > the processing layer, and this is what the dl does. But that is a 'core' function in VSh. And I see the core as being BL+PL or DL+BL+PL, not just the DL. > The actual communication protocol isn't very important, it is the api > that is being represented. Take a look at the communication protocol > for front to middle communication and the corba interface for dl to > bl communication. I don't see any kind of duplication between the two > and the dl is the code that is doing the translation. If we want to > try and connect a ui directly with a processing engine, then we will > either get a huge crazy interface for the processing engine to have to > deal with, or a ui that just mimics calls directly to the processing > engine. Well, it sounds to me like the DL is really inseparable from the BL+PL. So, we shouldn't have xDL:1BL as Jarl suggested; we should have xUI:1DL and 1DL:1BL. > The Overflow gui is a great example of making direct processing to > gui interface seen more natural. The gui is beautiful and (IMO) quite > intuitive to use, but in its underlying design is still guiizing calls > to functions. If you take a look at the menus they have tons of > selections, all corresponding to individual functions/calls, and their > xml design is set up to mimic a C program (as Jean-Marc was describing > earlier). However, this seems like it will be hard to expand to > include an arbitrary number of programs and be a "generalized" > application wrapper. I think the dl can make this transition feasible > (hopefully :). The PL (Overflow) will be both a low-level development system and a wrapper. It will wrap command-line programs the way it does now (maybe with some modifications). > I just don't understand the horrendous consequences you seem to see if > adding an extra communication layer. Maybe you could describe the > specific problems you see. Alright, I'll ask you this: Would you have come up with the extra comminication layer if you sat down and designed VSh from scratch? > > We COULD also consider combining Loci's middle with the VSh BL (using > > C-Python > > bindings). > > This is no different than communicating through corba, it is just a > different way to do it. CORBA is much more flexible since we can > change the interface while we are doing things, while wrappers will > make changing things a whole lot harder. You know, the 3 of us don't have a consistent view on this. I'm sure Jarl doesn't completely agree with you or I either. And we just can't proceed until we all know EXACTLY what each part does. I honestly don't know. I can't even figure out what will hold the network structure. Last time I asked Jarl, he didn't seem sure either. And I really want to know how many UI's per DL, how many DL's per BL, and how many BL's per PL. I'm in the dark trying to help answer these questions, but my answers are coming back as 'unacceptable' and 'you need to respect my code'. > I wasn't saying that I want complete design control--I know that I am > not a good designer, which is why I'm working on problems with other > people. I just want design decisions to be made respecting working > contributed code. Since we now have actual code, we can't afford to > make designs as if everything is vaporware, and need to work around > what we already have. I would say this even if it wasn't my own code > that we are talking about :-) Pardon me for the sarcasm, but should we then patch the GMS and Overflow GUI's into VSh somewhere? ;-) You haven't mentioned that at all. Brad, I think I abhor a patch-work, hodge-podge application as much as you hate throwing away code. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 03:36:29 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] genetic algorithms for scheduling Message-ID: <39054AFD.5080789C@geoserve.net> I thought this would be interesting to Jarl. The use of genetic algorithms for scheduling: http://www.us.flea.org/~horms/papers/honours1/html/thesis.html http://www.dai.ed.ac.uk/groups/outlook/estonia.html They're about scheduling human events, not computer events, but some things may be applicable to VSh. Jeff From jarl at casema.net Tue Apr 25 03:15:23 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] genetic algorithms for scheduling References: <39054AFD.5080789C@geoserve.net> Message-ID: <3905460B.FA288EE9@casema.net> "J.W. Bizzaro" wrote: > I thought this would be interesting to Jarl. The use of genetic algorithms > for scheduling: > > http://www.us.flea.org/~horms/papers/honours1/html/thesis.html > http://www.dai.ed.ac.uk/groups/outlook/estonia.html > > They're about scheduling human events, not computer events, but some things > may be applicable to VSh. A cool, i've been reading some about job scheduling before, but never enough :) From bizzaro at geoserve.net Tue Apr 25 05:11:11 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] appology Message-ID: <3905612F.76D99C48@geoserve.net> Brad, I did another read through many of the old (couple weeks old) e-mail messages that you and Jarl posted about the functions of the DL and BL. I think I understand things a bit better now. My confusion came from thinking that the BL (GMS) would handle most of the functionality of the current Loci middle. So, I questioned what the DL would be used for. But now I realize that the DL is the real 'middle' of VSh, or at least the middle used for network construction. I also see now where the split is between build-time (when the network is constructed by the user) and run-time (when the network is executed). Maybe in the summary could show this split: Build-Time System User Interfaces Definitions Layer Run-Time System Brokering Layer Processing Layer In recent e-mails, you were calling this 'run-time system' the 'processing system', which made me think you were talking about the PL. So, I'm sorry I was so hard on you :-) I will need to update my distributed filesystem specification to reflect my new understanding. Oh, and can you or Jarl draw a diagram showing how 2 remote sessions of VSh will work together? Also, I'd like us to consider making an ADDITIONAL UI2DL protocol using CORBA, so that interfaces can be made to use sockets OR CORBA. What do you think? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue Apr 25 04:25:50 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] appology References: <3905612F.76D99C48@geoserve.net> Message-ID: <3905568E.3257D546@casema.net> > > Build-Time System > User Interfaces > Definitions Layer > > Run-Time System > Brokering Layer > Processing Layer Sounds logical. > > Oh, and can you or Jarl draw a diagram showing how 2 remote sessions of VSh > will work together? Brad: shall we both make one, and wait for showing it to each other untill we're both ready. I'm curious how much we're having the same structure in mind? > > Also, I'd like us to consider making an ADDITIONAL UI2DL protocol using CORBA, > so that interfaces can be made to use sockets OR CORBA. What do you think? Corba is Good. Sockets are easy. :) And we could release a skeleton UI with all the corba stuff ready. bye, jarl From chapmanb at arches.uga.edu Tue Apr 25 07:14:29 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] apology Message-ID: <200004251116.HAA82206@archa10.cc.uga.edu> Jeff wrote: > I also see now where the split is between build-time (when the network is > constructed by the user) and run-time (when the network is executed). Maybe > in the summary could show this split: > > Build-Time System > User Interfaces > Definitions Layer > > Run-Time System > Brokering Layer > Processing Layer > > In recent e-mails, you were calling this 'run-time system' the 'processing > system', which made me think you were talking about the PL. Thanks for putting this all so succinctly and clearly. What I was _trying_ to say in my last message was that the dl is the glue that binds the Build-Time system with the Run-Time system. I apologize for not making things more clear. Jeff wrote: > Oh, and can you or Jarl draw a diagram showing how 2 remote sessions of VSh > will work together? Jarl wrote: > Brad: shall we both make one, and wait for showing it to each other untill > we're both ready. > I'm curious how much we're having the same structure in mind? Sounds like a fun game :-) Reminds me of science olympiad in high school when I was in the 'write-it/build-it' competition. One part of our group had a half hour to look at this crazy structure made out of Legos and write down a desciption of how to build it. Then the other part of our group had to take this desciption and the individual parts and try to build the original structure from the description. Hopefully in this case we won't come up with two completely different structures :-) > Also, I'd like us to consider making an ADDITIONAL UI2DL protocol using > CORBA, > so that interfaces can be made to use sockets OR CORBA. What do you think? Execellent idea. I'll put this on my mental ToDo list (but for later). I think it'll be interesting to see if people designing new user interfaces would rather use corba or sockets, so hopefully eventually we can migrate to one or the other (since upkeeping two could get to be a pain). I personally would rather this be corba, but it'll ultimately be up to user interface designers. Brad From chapmanb at arches.uga.edu Tue Apr 25 08:01:00 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] summary for web page and announcements Message-ID: <200004251203.IAA117196@archa10.cc.uga.edu> Jeff wrote: > And after we get that put up, I would like to make some announcements about > the collaboration. I know that we don't have a working system yet, but I can > mention that Overflow, GMS and Loci have merged. And I can mention what our > plans are. This is very important so that people know we are here, and so > that no-one tries to make a VSh of their own ;-) Well, before we start announcing we should probably actually decide on a final name for the program... I was thinking about this a bit in my genetics class and came up with an idea for a name: Hedgehog Why? What the heck are you talking about, Brad? Well, the hedgehog family of proteins are a really important set of molecules for controlling development in flies and mammalian systems. They are signal transduction proteins that pass developmental information from cell to cell and are responsible for proper formation of patterning in developing embryos (so they help detemine what if your back and front and right and left sides). So I thought this was analagous to vsh/loci/gms/overflow in the following way: Biology Our program -------- ---------- cell-cell communication => program-to-program communication proper embryo development => proper workflow development So Hedgehog is a protein that coordinates cells to develop in a good way, and vsh is a program that coordinates programs and libraries to flow together in a good way. Whadda you all think? The added advantages are that it has a easy acronym (hh) and that we can put pictures of hedgehogs on our site without people taking us away to the mental hospital :-) Brad From jarl at casema.net Tue Apr 25 07:33:30 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> Message-ID: <39058289.DB750D59@casema.net> > > Well, before we start announcing we should probably actually > decide on a final name for the program... Good thinking. > > Hedgehog > > Why? What the heck are you talking about, Brad? :) > > Well, the hedgehog family of proteins are a really important set > of molecules for controlling development in flies and mammalian > systems. They are signal transduction proteins that pass > developmental information from cell to cell and are responsible for > proper formation of patterning in developing embryos (so they help > detemine what if your back and front and right and left sides). > So I thought this was analagous to vsh/loci/gms/overflow in the > following way: > > Biology Our program > -------- ---------- > cell-cell communication => program-to-program communication > proper embryo development => proper workflow development > > So Hedgehog is a protein that coordinates cells to develop in a good > way, and vsh is a program that coordinates programs and libraries to > flow together in a good way. > > Whadda you all think? The added advantages are that it has a easy > acronym (hh) and that we can put pictures of hedgehogs on our site > without people taking us away to the mental hospital :-) At last! Hedgehog sounds ok, but aint there some other project around that's already using this name? bye, jarl -- byob, v: Believing Your Own Bull From jean-marc.valin at hermes.usherb.ca Tue Apr 25 08:42:41 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> Message-ID: <390592C1.1AB00200@hermes.usherb.ca> > So Hedgehog is a protein that coordinates cells to develop in a good > way, and vsh is a program that coordinates programs and libraries to > flow together in a good way. > > Whadda you all think? The added advantages are that it has a easy > acronym (hh) and that we can put pictures of hedgehogs on our site > without people taking us away to the mental hospital :-) I would prefer a name that has a meaning to everybody. Also, it has to reflect the fact that you can use the software for many applications, from biology to speech and image processing. I think it would be nice to have the word "flow" in the name (that's why I chose "Overflow") if possible (but I won't complain too much if we don't). Jean-Marc From bizzaro at geoserve.net Tue Apr 25 09:59:24 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] name game (was: summary for web page and announcements) References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> Message-ID: <3905A4BC.DCB75218@geoserve.net> Brad wrote: > > So Hedgehog is a protein that coordinates cells to develop in a good > way, and vsh is a program that coordinates programs and libraries to > flow together in a good way. > > Whadda you all think? The added advantages are that it has a easy > acronym (hh) and that we can put pictures of hedgehogs on our site > without people taking us away to the mental hospital :-) Jean-Marc Valin wrote: > > I would prefer a name that has a meaning to everybody. Also, it has to reflect > the fact that you can use the software for many applications, from biology to > speech and image processing. I think it would be nice to have the word "flow" in > the name (that's why I chose "Overflow") if possible (but I won't complain too > much if we don't). I think Hedgehog is cute. But being so, it is probably taken :-/ I guess I agree with Jean-Marc that the name should give the prospective user some indication as to what the program does. I get the Hedgehog analogy, but non-biologists would not. I was growing fond of VSh, particularly 'GNU Visual Shell'. I like it for the following reasons: * To say that the program is 'THE' visual shell for GNU is pretentious and presumptuous, and it will garner the attention the program deserves. * 'Visual Shell' and even VSh say exactly what we're the program is: a visual shell! The term is commonly used to describe graphical environments like Gnome, but I could find only one program that used it (in 1984) as a name. You know, but Gnome, KDE, and the stuff Eazel is working on...THAT'S ALL WIN/MAC CRAP! Let's show everyone how a true UNIX *shell* should work! * I *REALLY* want to have the word 'GNU' in the name. That alone will attract attention and tell people that this is free-as-in-speech software. A couple people pointed out to me that we could abbreviate 'GNU Visual Shell' as 'vshgnu' (like the Hindu god Vishnu). It'd be cute, if it isn't offensive to any Hindus ;-) And 'gnu' pronounced as 'new' can indicate that this is the 'New VSh' (the old VSh being from 1984). Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:07:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:49 2006 Subject: [Pipet Devel] Re: summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> <39059A45.D67A9136@redpoll.pharmacy.ualberta.ca> Message-ID: <3905A6B1.7E4013EA@geoserve.net> Gary Van Domselaar wrote: > > I know jeff like Vsh, and I'm okay with it I also like 'Loci' :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:11:41 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> Message-ID: <3905A79D.E586874F@geoserve.net> Jean-Marc Valin wrote: > > I would prefer a name that has a meaning to everybody. Also, it has to reflect > the fact that you can use the software for many applications, from biology to > speech and image processing. I think it would be nice to have the word "flow" in > the name (that's why I chose "Overflow") if possible (but I won't complain too > much if we don't). Please don't take this the wrong way, but the name 'Overflow' makes me think 'stack overflow error'. And you probably don't want to associate your program with a common error ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:15:39 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: name game (was: summary for web page and announcements) References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A4BC.DCB75218@geoserve.net> Message-ID: <3905A88B.DFB1FCD1@geoserve.net> "J.W. Bizzaro" wrote: > > A couple people pointed out to me that we could abbreviate 'GNU Visual Shell' > as 'vshgnu' (like the Hindu god Vishnu). And when we go to conferences, we can shave our heads, don pink robes, and sing, 'Hari Hari, Vshgnu Vshgnu, Hari Rama, Vshgnu Vshgnu' :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 10:20:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] apology References: <200004251116.HAA82206@archa10.cc.uga.edu> Message-ID: <3905A9BD.E80FC995@geoserve.net> Brad, Thanks for correcting my spelling, but 'appology' is 'the study of applications' ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Tue Apr 25 09:22:35 2000 From: jarl at casema.net (Jarl van Katwijk) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: name game (was: summary for web page and announcements) References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A4BC.DCB75218@geoserve.net> <3905A88B.DFB1FCD1@geoserve.net> Message-ID: <39059C1A.3937A146@casema.net> > > A couple people pointed out to me that we could abbreviate 'GNU Visual Shell' > > as 'vshgnu' (like the Hindu god Vishnu). > > And when we go to conferences, we can shave our heads, don pink robes, and > sing, 'Hari Hari, Vshgnu Vshgnu, Hari Rama, Vshgnu Vshgnu' :-) Uhh.. do we have to? :-) From jean-marc.valin at hermes.usherb.ca Tue Apr 25 11:06:53 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: summary for web page and announcements References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A79D.E586874F@geoserve.net> Message-ID: <3905B48D.7FE0011B@hermes.usherb.ca> > > I would prefer a name that has a meaning to everybody. Also, it has to reflect > > the fact that you can use the software for many applications, from biology to > > speech and image processing. I think it would be nice to have the word "flow" in > > the name (that's why I chose "Overflow") if possible (but I won't complain too > > much if we don't). > > Please don't take this the wrong way, but the name 'Overflow' makes me think > 'stack overflow error'. And you probably don't want to associate your program > with a common error ;-) Just to make it clear, I wasn't suggesting using Overflow, since it would make things confusing. I just though having the word "flow" in the name would tell a bit about what the software's doing. As for the 'stack overflow error' meaning, that was actually intended when we chose the name, so I don't feel offended. Jean-Marc From jarl at casema.net Tue Apr 25 13:04:31 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] collaboration naming References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A79D.E586874F@geoserve.net> <3905B48D.7FE0011B@hermes.usherb.ca> Message-ID: <3905D01F.DD31019C@casema.net> Hi all, because all three projects need to be covered by a name, seems we need something that covers the - visual shell aspect of Loci, - the flowing of Overflow - the message orientation of gms We also might take the GP part into account. BUT we could just take a cool name, I did some searching and came across this: Trias. see the greek diactionary online http://www.perseus.tufts.edu/cgi-bin/lexindex?lookup=tria/s&lang=Greek&author=*2.0&corpus=2.0 for the translation. It means (among other things) 'System of Three'. There's no project with this name as far as I can find. And it sounds nice & distinctable. bye, jarl From jean-marc.valin at hermes.usherb.ca Tue Apr 25 14:09:45 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] collaboration naming References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A79D.E586874F@geoserve.net> <3905B48D.7FE0011B@hermes.usherb.ca> <3905D01F.DD31019C@casema.net> Message-ID: <3905DF69.5F53AB17@hermes.usherb.ca> > because all three projects need to be covered by a name, > seems we need something that covers the > - visual shell aspect of Loci, > - the flowing of Overflow > - the message orientation of gms That leaves "Visual Message Flow" ;-) Seriously, how about something like "VDevelop", "VFlow", ... Jean-Marc From jarl at casema.net Tue Apr 25 13:25:06 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] collaboration naming References: <200004251203.IAA117196@archa10.cc.uga.edu> <390592C1.1AB00200@hermes.usherb.ca> <3905A79D.E586874F@geoserve.net> <3905B48D.7FE0011B@hermes.usherb.ca> <3905D01F.DD31019C@casema.net> <3905DF69.5F53AB17@hermes.usherb.ca> Message-ID: <3905D4F2.B0F015EE@casema.net> > > because all three projects need to be covered by a name, > > seems we need something that covers the > > - visual shell aspect of Loci, > > - the flowing of Overflow > > - the message orientation of gms > > That leaves "Visual Message Flow" ;-) > Seriously, how about something like "VDevelop", "VFlow", ... > I feel more for something like Trias because this has character, like gnome or samba have. Those are names that show respect to the project. Maybe we could come up with some name that's like gnome: a nice name that's also an abbreviation. From gvd at redpoll.pharmacy.ualberta.ca Tue Apr 25 17:40:33 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] name game Message-ID: <390610D1.984295@redpoll.pharmacy.ualberta.ca> so noone liked DataFlower? I'm crushed :-( -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From deanne at density.biop.umich.edu Tue Apr 25 18:02:10 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] collaboration naming In-Reply-To: <3905D01F.DD31019C@casema.net> Message-ID: trio (tr) n., pl. trios. 1.A group of three people or things joined or associated. 2.Music. a.A composition for three performers. b.The group performing such a composition. c.The middle section of a minuet or scherzo, a march, or of various dance forms. Close to "Trias", too TRIO: T(something) R(something) Input with Overflow? Just musing, and lurking as usual. (I'm trying to FIND a job in bioinformatics at this point...talk about difficult...still here, just caught up in other foo). Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor On Tue, 25 Apr 2000, jarl van katwijk wrote: > Hi all, > > because all three projects need to be covered by a name, > seems we need something that covers the > - visual shell aspect of Loci, > - the flowing of Overflow > - the message orientation of gms > > We also might take the GP part into account. > > BUT we could just take a cool name, I did some searching and came across this: > > Trias. > > see the greek diactionary online > http://www.perseus.tufts.edu/cgi-bin/lexindex?lookup=tria/s&lang=Greek&author=*2.0&corpus=2.0 > for the translation. It means (among other things) 'System of Three'. > > There's no project with this name as far as I can find. > And it sounds nice & distinctable. > > bye, > jarl > > > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel > From bizzaro at geoserve.net Tue Apr 25 23:35:55 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: name game References: <390610D1.984295@redpoll.pharmacy.ualberta.ca> Message-ID: <3906641B.EB8CE7FE@geoserve.net> Gary Van Domselaar wrote: > > so noone liked DataFlower? I'm crushed :-( Crushed like a little flower, dataflower that is ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Tue Apr 25 23:51:51 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: collaboration naming References: Message-ID: <390667D7.62E9CFD@geoserve.net> deanne@density.biop.umich.edu wrote: > > Close to "Trias", too TRIO: T(something) R(something) Input with Overflow? They're nice suggestions, really. I am partial to Latin and Greek words, as evidenced by my choice of "Loci" for one of the "triad" projects. But, I wouldn't want to emphasize that there are distinct and separate parts to this project, or that 3 programs were glued together (there are actually 4 layers to the project, BTW). People should see this as a single program and not have to be reminded of the collaboration behind it (So, "Unum" and "Unisys" are out too ;-)). This could have been a collaboration of 2, 3, 4, 5, 6, etc. projects, and what difference would it make to the user? It says nothing about what the program DOES...and it doesn't give us a cute mascot either ;-) > (I'm trying to FIND a job in bioinformatics at this point...talk about > difficult...still here, just caught up in other foo). Bioinformatics.org will soon have a section for posting job opportunities in the field. You may want to stay tuned for that. Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 01:06:45 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Pipewave signal processing software Message-ID: <39067965.EF11748A@geoserve.net> This might be something to consider porting to * (whatever we'll call it): http://www.cf.ac.uk/psych/CullingJ/pipewave.html BTW, how about the name "pipeline"? Jeff From bizzaro at geoserve.net Wed Apr 26 01:13:47 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] name References: <39067965.EF11748A@geoserve.net> Message-ID: <39067B0B.49317A54@geoserve.net> > BTW, how about the name "pipeline"? pipeline piper pipes gnupipes ("new pipes") Maybe even... plumber visual pipes tubes pvc copper They convey the idea of "flow", don't they? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 02:13:10 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] NETPIPES Message-ID: <390688F6.A744B2AA@geoserve.net> http://web.purplefrog.com/~thoth/netpipes/netpipes.html Jeff From bizzaro at geoserve.net Wed Apr 26 03:33:21 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: name References: <39067965.EF11748A@geoserve.net> <39067B0B.49317A54@geoserve.net> Message-ID: <39069BC1.7C90214E@geoserve.net> "J.W. Bizzaro" wrote: > > pipeline > piper > pipes > gnupipes ("new pipes") > plumber > visual pipes > tubes > pvc > copper and... pipeworks Alright, I stop the e-mail barrage Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 03:53:30 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: name References: <39067965.EF11748A@geoserve.net> <39067B0B.49317A54@geoserve.net> <39069BC1.7C90214E@geoserve.net> Message-ID: <3906A07A.9D7E99FA@geoserve.net> "J.W. Bizzaro" wrote: > > piper I like piper. Then I can call my gnome UI "pied" ("patchy colors" as in "The Pied Piper"). And we can have The Pied Piper as a mascot :-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Wed Apr 26 23:40:03 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper Message-ID: <3907B693.A8C12939@geoserve.net> Does anyone like the name "piper"? Look at the sandpiper pic attached. Aint it cute? :-) Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: sandpiper.jpg Type: image/jpeg Size: 31743 bytes Desc: not available Url : http://bioinformatics.org/pipermail/pipet-devel/attachments/20000427/7937f5c0/sandpiper-0001.jpg From deanne at density.biop.umich.edu Wed Apr 26 23:40:47 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper In-Reply-To: <3907B693.A8C12939@geoserve.net> Message-ID: I like "piper"... |-er |er Heh. Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor On Thu, 27 Apr 2000, J.W. Bizzaro wrote: > Does anyone like the name "piper"? > > Look at the sandpiper pic attached. Aint it cute? :-) > > Jeff From jean-marc.valin at hermes.usherb.ca Wed Apr 26 23:53:44 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: Message-ID: <3907B9C8.3E0591E8@hermes.usherb.ca> deanne@density.biop.umich.edu a ?crit : > > I like "piper"... I also think it's a good name. Another think to think about though is that we need to find a project name, but we'll need to find names for the different apps in the project. For example in the Overflow project, there are the "VFlow" and "batchflow" apps. It would be nice to have related names for apps. Any idea of a "theme" around "piper"? Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From deanne at density.biop.umich.edu Thu Apr 27 00:35:04 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: [Pipet Devel] Re: [Pipet Devel] piper In-Reply-To: <3907B9C8.3E0591E8@hermes.usherb.ca> Message-ID: > > I also think it's a good name. Another think to think about though is that we > need to find a project name, but we'll need to find names for the different apps > in the project. For example in the Overflow project, there are the "VFlow" and > "batchflow" apps. It would be nice to have related names for apps. Any idea of a > "theme" around "piper"? > [Nouns] musician, artiste, performer, player, minstrel; bard (poet) [more]; accompanist, accordionist, instrumentalist, organist, pianist, violinist, flautist; harper, fiddler, fifer, trumpeter, piper, drummer; catgut scraper. http://scottishculture.about.com/culture/scottishculture/library/blhumpipes.htm?rnk=r7&terms=piper ...and I want to author an application called 'haggis'. :) How about fifer, fiddler? Bard? (above is from www.thesaurus.com) From bizzaro at geoserve.net Thu Apr 27 00:55:13 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] Re: piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> Message-ID: <3907C831.777F747@geoserve.net> Jean-Marc Valin wrote: > > I also think it's a good name. Another think to think about though is that we > need to find a project name, but we'll need to find names for the different apps > in the project. For example in the Overflow project, there are the "VFlow" and > "batchflow" apps. It would be nice to have related names for apps. Any idea of a > "theme" around "piper"? There are lots of words associated with "piper" and "pipe" that would give us a theme: pied (as in "pied piper" fairy tale) (anything to do with the fairy tale - e.g., "rats", "Hamelin", "legend") drummer (as in "piper and drummer") (anything to do with pipe or flute playing - e.g., "bag piper", "pipe organ", "tabor") sand (as in "sandpiper"; also species "peep", "knot", "sanderling") (anything to do with sandpipers or birds - e.g., "shore", "footprint", "winged") (anything to do with Piper airplanes - e.g., "Cub", "Saratoga") peter (as in "Peter Piper picked a pack of pickled peppers") pepper (plant of the "piperaceae" taxonomic order; also "piperine") (anything to do with water pipes and plumbing - e.g., "pipeline", "steam pipe") pay (as in "pay the piper") dream (as in "pipe dream") bomb (as in "pipe bomb") (anything to do with tobacco pipes - e.g., "peace pipe") Whew! Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu Apr 27 06:35:01 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> Message-ID: <390817D5.B4E7991D@casema.net> > > > > I like "piper"... > I'm ok with Piper to. Funny aspect is in dutch language a word with the same pronunciation has an embarrassing meaning :) jarl. From bizzaro at geoserve.net Thu Apr 27 07:53:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> Message-ID: <39082A57.6EA41E1B@geoserve.net> jarl van katwijk wrote: > > I'm ok with Piper to. > > Funny aspect is in dutch language a word with the same pronunciation has > an embarrassing meaning :) Alright, now you have to tell us what word and what meaning :-) Oh, and how do you pronounce "piper" in Dutch? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From bizzaro at geoserve.net Thu Apr 27 08:04:35 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> Message-ID: <39082CD3.1931C8F4@geoserve.net> jarl van katwijk wrote: > > I'm ok with Piper to. The vote is... Jeff: YES Jean-Marc: YES Jarl: YES (Deanne: YES) Still missing: Brad: Flower^H^H^H^H^H^HGary: Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu Apr 27 07:00:20 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> <39082A57.6EA41E1B@geoserve.net> Message-ID: <39081DC4.BE613F04@casema.net> > jarl van katwijk wrote: > > > > I'm ok with Piper to. > > > > Funny aspect is in dutch language a word with the same pronunciation has > > an embarrassing meaning :) > > Alright, now you have to tell us what word and what meaning :-) Oh, and how > do you pronounce "piper" in Dutch? > Pijper = somebody who gives a blow job. The differance in pronounsation is that in dutch the 'ij' is spoken like the 'ie' in 'die'. From bizzaro at geoserve.net Thu Apr 27 08:17:02 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> <39082A57.6EA41E1B@geoserve.net> <39081DC4.BE613F04@casema.net> Message-ID: <39082FBE.DED72B95@geoserve.net> jarl van katwijk wrote: > > Pijper = somebody who gives a blow job. Now there's a good name for the project ;-) And I imagine the words share a common etymology :-P > The differance in pronounsation is that in dutch the 'ij' is spoken like the > 'ie' in 'die'. Hmmm. But in English, you'd pronounce "piper" as "pie - per". Isn't it the same in Dutch? Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From deanne at density.biop.umich.edu Thu Apr 27 08:15:10 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper In-Reply-To: <39082FBE.DED72B95@geoserve.net> Message-ID: *cough* Just imagine the "alternate project names" with THAT one. (deanne) Deanne Taylor Biophysics Graduate Program lilyth@umich.edu University of Michigan http://www.umich.edu/~lilyth Ann Arbor On Thu, 27 Apr 2000, J.W. Bizzaro wrote: > jarl van katwijk wrote: > > > > Pijper = somebody who gives a blow job. > > Now there's a good name for the project ;-) And I imagine the words share a > common etymology :-P > > > The differance in pronounsation is that in dutch the 'ij' is spoken like the > > 'ie' in 'die'. > > Hmmm. But in English, you'd pronounce "piper" as "pie - per". Isn't it the > same in Dutch? > > Jeff > -- > +----------------------------------+ > | J.W. Bizzaro | > | | > | http://bioinformatics.org/~jeff/ | > | | > | BIOINFORMATICS.ORG | > | The Open Lab | > | | > | http://bioinformatics.org/ | > +----------------------------------+ > > _______________________________________________ > pipet-devel maillist - pipet-devel@bioinformatics.org > http://bioinformatics.org/mailman/listinfo/pipet-devel > From jarl at casema.net Thu Apr 27 07:22:07 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> <39082A57.6EA41E1B@geoserve.net> <39081DC4.BE613F04@casema.net> <39082FBE.DED72B95@geoserve.net> Message-ID: <390822DF.D865B901@casema.net> > > > > Pijper = somebody who gives a blow job. > > Now there's a good name for the project ;-) And I imagine the words share a > common etymology :-P > > > The differance in pronounsation is that in dutch the 'ij' is spoken like the > > 'ie' in 'die'. > > Hmmm. But in English, you'd pronounce "piper" as "pie - per". Isn't it the > same in Dutch? No, the dutch 'ij' is created in the front of your mouth.. I dont know how to explain, I'm not linguist. bye, jarl From bizzaro at geoserve.net Thu Apr 27 08:31:48 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: Message-ID: <39083334.45315488@geoserve.net> deanne@density.biop.umich.edu wrote: > > Just imagine the "alternate project names" with THAT one. Many more names than with piper, I'm sure. > (deanne) Yeah, (deanne) in parentheses. I meant no offense by it. I was emphasizing the votes of the coordinators of the 3 merging projects. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jarl at casema.net Thu Apr 27 07:27:04 2000 From: jarl at casema.net (jarl van katwijk) Date: Fri Feb 10 19:19:50 2006 Subject: [Pipet Devel] piper References: Message-ID: <39082408.7F0220E7@casema.net> > *cough* > > Just imagine the "alternate project names" with THAT one. > > (deanne) Or the project symbol on the homepage :-) From deanne at density.biop.umich.edu Thu Apr 27 08:26:23 2000 From: deanne at density.biop.umich.edu (deanne@density.biop.umich.edu) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] piper In-Reply-To: <39083334.45315488@geoserve.net> Message-ID: > > > (deanne) > > Yeah, (deanne) in parentheses. I meant no offense by it. I was emphasizing > the votes of the coordinators of the 3 merging projects. I was only joking, Jeff. As you get to know me, you'll find out I have a pervasive sense of twisted humor. :) D From bizzaro at geoserve.net Thu Apr 27 08:43:33 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] piper References: Message-ID: <390835F5.9E0BDDBD@geoserve.net> deanne@density.biop.umich.edu wrote: > > I was only joking, Jeff. As you get to know me, you'll find out I have a > pervasive sense of twisted humor. :) Hey, "Twisted" my middle name. No..."William" is ;-) Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From chapmanb at arches.uga.edu Thu Apr 27 09:04:32 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] piper Message-ID: <200004271306.JAA126580@archa11.cc.uga.edu> > The vote is... > > Jeff: YES > Jean-Marc: YES > Jarl: YES > (Deanne: YES) > > Still missing: > > Brad Shore. Count me in. But only if we only refer to the definition layer as Piper at the Gates of Dawn... > Flower^H^H^H^H^H^HGary: I'll stick up for Gary (along with Jennifer) and say that DataFlower was my favorite name :-) I guess us Botanists are all biased, tho. Brad From bizzaro at geoserve.net Thu Apr 27 09:15:59 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] piper References: <200004271306.JAA126580@archa11.cc.uga.edu> Message-ID: <39083D8F.1E28E285@geoserve.net> Brad Chapman wrote: > > Shore. Count me in. But only if we only refer to the definition layer > as Piper at the Gates of Dawn... Kind of a long name :-) I want Pied Piper for the Gnome UI. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From gvd at redpoll.pharmacy.ualberta.ca Fri Apr 28 02:25:56 2000 From: gvd at redpoll.pharmacy.ualberta.ca (Gary Van Domselaar) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] piper References: <3907B9C8.3E0591E8@hermes.usherb.ca> <390817D5.B4E7991D@casema.net> <39082CD3.1931C8F4@geoserve.net> Message-ID: <39092EF4.9C57111C@redpoll.pharmacy.ualberta.ca> "J.W. Bizzaro" wrote: > > jarl van katwijk wrote: > > > > I'm ok with Piper to. > > The vote is... > > Jeff: YES > Jean-Marc: YES > Jarl: YES > (Deanne: YES) > > Still missing: > > Brad: > Flower^H^H^H^H^H^HGary: Piper is absotively fantabulous. g. -- Gary Van Domselaar gary@bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/ From chapmanb at arches.uga.edu Sat Apr 29 09:30:15 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] Random design thoughts Message-ID: Hello all! I've been doing a lot of thinking about the design of Loci/VSh/Piper, and especially about the ideas Jeff has had about combining the middle (dl) and front (ui) back together. In thinking about this, I was trying to kind of find some good models to look at the might have also tried the approach of having the user interface separated from the main functionality of the program through a communication layer. In our case, we are currently using a streaming XML dialog to separate these two layers. In my opinion, this approach is really cool because it provides us the ability to have multiple user interfaces in any language imaginable. So anyways, in my searching I started taking a look at the Berlin project (http://www.berlin-consortium.org) and think its kind of interesting that they use a similar separation of processing from user interface. If you check out http://www2.berlin-consortium.org/wiki/html/Berlin/HowBerlinUsesCORBA.htm, they have a terse description of this separation. Although they use CORBA (and not sockets like we have) the basic design seems to be the same--looking at it from our perspective the front (ui) makes calls to the middle (dl) to modify an xml description of the user interface, and then return info back upon completion of the modification. I just thought this might be good food for discussion, as it is kind of cool to me to see a really similar model... Also, if anyone is interested, there is a redesigned dl (middle) in cvs along with documentation (yay!) on the new structure of the code and on the overall design plan for the dl in general. Comments are more than welcome :-) The immediate plan for the middle (dl) is connection with gms (the bl) so we'll see how that goes... Thanks for listening. Brad From chapmanb at arches.uga.edu Sat Apr 29 12:59:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] Another idl question Message-ID: <200004291701.NAA21168@archa11.cc.uga.edu> Hey Jarl; Hope your weekend is going snazzy :-) I had another idl question for you concerning the Representation::upload() function: I'm confused about the bl returning a uri for this function. It seems like the dl will need to know the uris for each node and subnet, and so I don't know if the bl can return this information. So how about instead have the dl be responsible for assigning uris to everything in the xml document, something like: The first id will have to be the same for everything submitted by a dl, and the other ids will either just be assignments made by the dl (for instance, the subnet id above), or uris for "well-known" programs or libraries in the bl (which would be obtained from Obtain::programIds()). Does this make sense or am I off base here? Brad From bizzaro at geoserve.net Sat Apr 29 15:52:22 2000 From: bizzaro at geoserve.net (J.W. Bizzaro) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] announcement Message-ID: <390B3D76.AB0097CD@geoserve.net> My fellow Pipers, After we get the summary up on the web page, I want to send some announcements to a couple places: Gnome Gnotices Freshmeat (any others?) Jarl just mentioned to me that we should emphasize that the project is rather experimental, and not the all to end all. I agree. Are there any suugestions on just what we should say in the announcement? Cheers. Jeff -- +----------------------------------+ | J.W. Bizzaro | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG | | The Open Lab | | | | http://bioinformatics.org/ | +----------------------------------+ From jean-marc.valin at hermes.usherb.ca Sat Apr 29 16:14:00 2000 From: jean-marc.valin at hermes.usherb.ca (Jean-Marc Valin) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] announcement References: <390B3D76.AB0097CD@geoserve.net> Message-ID: <390B4288.1F3DDB4C@hermes.usherb.ca> "J.W. Bizzaro" a ?crit : > > My fellow Pipers, > > After we get the summary up on the web page, I want to send some announcements > to a couple places: > > Gnome Gnotices > Freshmeat > (any others?) > > Jarl just mentioned to me that we should emphasize that the project is rather > experimental, and not the all to end all. I agree. > > Are there any suugestions on just what we should say in the announcement? Scientific Applications for Linux (SAL.KachinaTech.com) LinuxDev.net (linuxtoday?) Jean-Marc -- Jean-Marc Valin Universite de Sherbrooke - Genie Electrique valj01@gel.usherb.ca From chapmanb at arches.uga.edu Sun Apr 30 15:48:23 2000 From: chapmanb at arches.uga.edu (Brad Chapman) Date: Fri Feb 10 19:19:51 2006 Subject: [Pipet Devel] Fun with ORBs Message-ID: <200004301950.PAA78636@archa11.cc.uga.edu> Hello all; I've been workin' on setting up Loci to talk with GMS though a corba interface. I've been attempting to use orbit-python (http://projects.sault.org/orbit-python/) so we could stay with one ORB implementation (ORBit) for the whole project. However, now that I have gotten into actually using these bindings, I'm running into a huge snag. The problem is that you can only import the idl file (orbit-python uses this instead of generating stub and skeleton code that you import) in the __main__ module, so things will only work if you are running a simple program in a main script. This is a known deficiency of orbit-python (ie. mentioned on the TO-DO list), and prevents us from using orbit-python to do what we want to do. I spent some time looking at the code and comparing it to CORBA::ORBit (the perl bindings to ORBit, which implement a similar idl import method) and I don't really see a simple fix for this problem at all. The orbit-python project is also stalled (no new code in a month and a half) so I'm not sure how things will progress there... So, I'm going to have to switch to a new ORB implementation for the python part of the program so we can have something functional and I wanted to try and get people's opinion on which ORB we should switch to for python. Here are the choices: Fnorb (http://www.fnorb.org/). ----- Advantages: o Easy to install becuase it is almost all python. Disadvantages: o Doesn't follow the official OMG python mapping (http://www.omg.org/cgi-bin/doc?ptc/00-01-12) so it'll require code changes later (not too big a deal for clients, but more of a pain for servers). o Pretty slow because of all the python. o I think the license is for non-commerical use only. ILU (ftp://ftp.parc.xerox.com/pub/ilu/ilu.html) ---- Advantages: o Has both C and python bindings, so if we wanted to we could switch to using only ILU. o Has a compatible license (I'm pretty positive about this--they've changed it since the problem with gnome or whatever). Disadvantages: o Their implementation of the official python mapping in the latest release isn't quite correct due to mistakes in the OMG document, so this will require some code changes later. omniORBpy (http://www.uk.research.att.com/omniORB/omniORBpy/) --------- Advantages: o Follows the official mapping. o Supposedly pretty fast. o Has a compatible license (LGPL or GPL, your choice). Disadvantages: o Can be a pain to install (at least for me :-). So anyways, those are our choices. What does everyone think about all of this? I'd really like to hear everyone's opinion about what we should do. Thanks for listening. Brad From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:11 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:20:08 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21224@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] Overview > --- Bodytext delivered in separate SMS messages --- (1/2) > The others probably don't understand what we mean by 'XML representation'. The dataflow structure? __ pipet-devel maillist - pipet-devel@bioinformatic (2/2) s.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:10 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:20:09 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21219@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] Project Design > --- Bodytext delivered in separate SMS messages --- (1/3) > > > > Could somebody collect all the design proposals and wishes and stuff and put > > them on > > the VSH page. Sometimes I'm saying\reading things twi (2/3) ce :) > > Alright, but in what form? As e-mail or a little more polished? > just copy-paste the emails, but organised by subject. More polished would be (3/3) nice, if somebody got the time :) __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:25 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:20:09 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21255@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] Re: Ideas for network distributed objects > --- Bodytext delivered in separate SMS messages --- (1/4) > > Hmm? Please explain, I can't pinpoint what you're trying to say. > > Notice the heirarchy of widgets. NOW THIS IS IMPORTANT: The heirarchy of > nodes (2/4) in a subnet, plus the XML descriptions of their interfaces, can be used > to arrange widgets and construct a GUI! > > This is all in the Loci archives wh (3/4) ere we discussed 'composited GUIs' and > 'constructing the command-line'. I'll certainly be talking more about this > later, as it is a major design feat (4/4) ure of Loci. > OK, got it. __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:00 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:20:09 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21188@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] Project Design > --- Bodytext delivered in separate SMS messages --- (1/5) jarl van katwijk wrote: > > Could somebody collect all the design proposals and wishes and stuff and put > them on > the VSH page. Sometimes I'm saying\re (2/5) ading things twice :) Alright, but in what form? As e-mail or a little more polished? Jeff - +----------------------------------+ | J.W. Bizzar (3/5) o | | | | http://bioinformatics.org/~jeff/ | | | | BIOINFORMATICS.ORG (4/5) | | The Open Lab | | | | http://bioinformatics.org/ | +---------------------------------- (5/5) + __ pipet-devel maillist - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:09 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:20:09 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21214@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: "j.w. bizzaro" : Re: [Pipet Devel] Overview > --- Bodytext delivered in separate SMS messages --- (1/10) Brad Chapman wrote: > > 2. A method for requesting a list of programs/libraries registered > with the processing engine. I think the "middle" should kee (2/10) p XML > descriptions of these separate from the processing engine, so this way > we can keep the messaging objects light weight (ie. they don't need > a (3/10) ny knowledge of the description or other info about a program--just > how to run it and get stuff back from it). Absolutely. Libraries, etc. for the GU (4/10) I are only REFERRED to via URI. This stuff may already be available on the local host, so to minimize transfer, the local host is given the OPTION to g (5/10) et a remote copy or use the local one. This is an old Loci discussion (initiated by Humberto and Justin IIRC). Which reminds me, we should also send li (6/10) brary version information in the stream. That way, the local system will know if a newer version is available. > This way the "middle" can > also keep t (7/10) he XML files for programs organized into directories of > similar programs, so they will be easy to find for the user. However, > before giving a GUI ac (8/10) cess to a program representation, it will need > to confirm with the middle that the (? I think you fell asleep typing this ;-)) The others probably don (9/10) 't understand what we mean by 'XML representation'. > 3. Methods for querying the middle to determine the "status" of a > process. Right. BTW, I want t (10/10) o have a status 'symbol' (no pun intended) displayed for and with each node. > I would be happy to have one. I'm all about structure etc. The way my > l > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:26:59 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:20:09 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192026.WAA21181@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] gui protocol revisited > --- Bodytext delivered in separate SMS messages --- (1/6) > > communiate with the GUI front via the streaming XML dialog you > > describe. > > Okay, if you like that. And I guess Jarl likes it too. Yes. sure is. (2/6) > > I'm a little confused about this 'processing part of the program'. Is this > something GMS or Overflow has now? Is it something you'll have to writ (3/6) e? After some time when the 'basics' work, non-technical users will be excluded from using VHS, so there must be some meganism to automatie the creation o (4/6) f data flow. 1) applications can supply a VSH 'script' that intergrate that application to VSH, 2) to analyze 'good' structures and apply them to other in (5/6) stances of VSH. 1) is easy, but 2) requires an anaylize 'core' (CFS\GAP on the the GMS page) Both are far-future idears though :) __ pipet-devel maillist (6/6) - pipet-devel@bioinformatics.org http://bioinformatics.org/mailman/listinfo/pipet-devel > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox. From email.sms at gsm.wanadoo.nl Wed Apr 19 17:27:32 2000 From: email.sms at gsm.wanadoo.nl (Email to SMS gateway - Dutchtone) Date: Fri Feb 10 19:20:09 2006 Subject: [Pipet Devel] Sent SMS message to +31628672599 Message-ID: <200004192027.WAA21289@mailer.gin.nl> Thanks for using our service, your message has been sent to +31628672599. > --- Actual message sent using SMS --- email from: jarl van katwijk : Re: [Pipet Devel] gui protocol revisited > --- Bodytext delivered in separate SMS messages --- (1/10) > > Well, I wanted to attach it to the idl I sent out yesterday. Yes, I will work on the IDL this weekend, we'll can have a pretty good one done in (2/10) a few days. Implementing the idl will take some longer. > > I'm not really very clear right now how GMS and Overflow will > combine and work togeth (3/10) er (I'll need to dig more into the code to know > this for sure) Overflow will work as it does standalone, and gms will pass on the calls from and to th (4/10) e gui. > As I said, I'd like this combination of GMS and Overflow to wrap into > one idl (the one I sent out). Yes, right. > Along these lines, I'd (5/10) like to try and dig more into Overflow and > GMS code and start working with it. This will probably help us firm up > the communication between the 'mid (6/10) dle scripting engine' and the > 'processing part' and help get the idl straightened out and all. So... > I was going to throw myself out to the wolves a (7/10) nd ask if Jarl and > Jean-Marc and Dominic have parts of GMS and Overflow that they'd like > me to work on/with, to help towards our integration goal. T (8/10) hese can be > small short term projects or whatever, but I'd like to help in this > regard, and it would help me be more familiar with what is going on (9/10) > and actually be able to make more non-vague suggestions :-) > So could we work something like this out? Sure, but first let us define that GUI <-> (10/10) Engine idl. When we got that ready, things will be much more clear I guess. > I think we sort of have a design down, although at least in my > thin > --- End of message --- PLEASE NOTE: Because of the limitations of Short Messages (length max 160 characters) we will only send the subject field of your email to the GSM phone. All data in the body of the message will be lost, unless the recipient has set the receiption of bodytekst to ON. For more information call Dutchtone customer care Dutchtone Email SMS Service. NOTE: This message is an automatic delivery report. If you did not send your email to a 'Dutchtone' mailbox, the original addressee probably has an invalid mail forwarding rule installed. You could help us to stop sending unwanted reports by telling your addressee to forward his mail to (GSMnumber)@gsm-notificatie.wanadoo.nl instead of (GSMnumber)@gsm.wanadoo.nl. No delivery confirmation messages will be auto-sent using that mailbox.