>> 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