"J.W. Bizzaro" wrote: > > jarl van katwijk wrote: > > > > As I mentioned earlier: the first subject of discussion should be the differance > > between the classes\objects 'filosophy' of both systems.. I think your choose > > to implement different types based upon functionality isn't the way it should be > > done. I'm supporting the 'one global do-everything object". > > > > I'm very curious why Loci classes are implemented the way they are... Jarl, Loci's philosophy follows that of the unix philosophy: one function, one application. Sophisticated, distributed data processing is accomplished by pipelining these 'simple' applications toghether. The 'all-inclusive' approach that GMS takes for brokering datastreams is also valid. One consideration for Loci, however, is that it is intended ultimately to act as a graphical scripting language for distributed data brokering. The processing applications exist already; Loci wraps these applications, and adds 'extras' to the workpath (like data format conversion utilities) in order for the data to stream properly between different applications. Other 'elemental loci' include data storage utilities, which can be customized to store an incoming data stream based on user defined schemas, possibly so that they can process it further later using non Loci-wrapped processing applications, or perhaps to view the data with their favorite viewing application. In our world of computational biology, this is a requirement, so modularity and simplicity are a big part of the Loci philosophy. An additional consideration arises from the following scenario: a simple workflow diagram can be encapsulated into a 'node' which is itself capable of being inserted into another workpath, and so on, ad infinitum. An apparently simple workpath may be in reality composed of multiply nested workpaths and can in principle be quite complex. In order to minimize bloat, our thinking was to minimize each type of elementary node to its basic functionality. IMHO, I don't think there is a 'right' or 'wrong' way to design the elementary objects. This is all good food for thought, and I suggest we (Loci, GMS, and Overflow) create a discussion forum where we can have open discussions on the best way to implement this core functionality. The Locians are a very open-minded group; thats one of the reasons why we discussed our project for so long before committing to writing code. Lucky that we did, since we have so recently made contacts with such useful potential allies! I am currently working on creating a web-based open source development environment for our organization: bionformatics.org. It is based on the sourceforge development environment (http://sourceforge.net). It is a sophisticated and very user-friendly environment intended to foster discussions and collaborations of the nature in which we are currently engaged. I can set up a forum for you, Jean-Marc (canadian, yaay;-) and the locians to hash out the details of our architectures, design goals, and hopefully generate a powerful collaboration for creating the sophisticated data processsing environment that we are all so passionate about. > > Perhaps you can give us a synopsis/summary of the GMS object philosophy. It > would then be easier for me to point out differences, because right now I'm > not so sure how GMS is different. I can see from the dia flowchart on your homepage that you have a well thought out architecture for your core operation, but some of the acronyms are a little too obscure for me. If you could provide a couple of paragraphs describing the operation of your 'core' for us, that too would be greatly appreciated. Regards, g. -- Gary Van Domselaar gary at bioinformatics.org http://www.bioinformatics.org/~gary ---------------------------------------------------- bioinformatics.org: The Open Lab http://www.bioinformatics.org/