[Pipet Devel] summary for web page and announcements

[Brad Chapman]

> 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