> 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