Hi, Jon. Jon Stevens wrote: > Ok. Now you are getting personal (by comparing to Turbine) and making a > complete fool of yourself with your ridiculous FUD statements.
I believe Jeff asked me how BOX compares with other technologies. I'm pointing out some aspects where I believe BOX to be better (i.e., simpler). How can I avoid such comparisons of details when I was specifically asked to compare technologies? (As the saying goes, "The devil is in the details.") As for FUD, I see no reason to view what I write as encorporating fear, uncertainty, or doubt in any of the current technologies that are being compared. Each of the technologies available have their strengths and weaknesses. BOX, for example, can't do many of the things that Cocoon is capable -- but the niches are somewhat different. Where Cocoon does everything, at the cost complexity, BOX focuses on a subset of the problems Cocoon solves. > BOX is just another wannabe web framework that is inventing yet more To me, the term "wannabe" implies that it _isn't_ a web framework. Please review the original document (http://www.joot.com/box) and let me know where, in that description, you come to the conclusion it isn't a web framework. Then, either please retract the word "wannabe", or please explain how you've used the term "wannabe" in a sense that isn't negative. :-) Thanks. > technologies and claiming to be the 'best' because you happen to like it and > it works for you. I have never claimed it to be "the 'best'". Please point out exactly where I said BOX is the best, or stop saying things on my behalf. I apologize if this is the impression I've given; it is certainly not what was intended. I have, on numerous occasions, pointed out aspects of BOX that are _simpler_ than other technologies. (In many cases simpler is indeed better, but not always best.) What I'm trying to illustrate is that BOX architecture makes life very easy for e-commerce sites that follow the algorithm I've outlined in a previous message: 1) Send HTML to browser. 2) Get information from browser. 3) Do something with that information (database, file, simple calculations) 4) Repeat from Step 1. Yes, I like it. It's simple. Yes, it works for me. But it wasn't developed with me in mind. It was developed because I saw a problem in the industry that needed a simple solution. I couldn't find one, so wrote something simple and extensible, building upon neutral technologies (XML, XSL, HTML, etc.) to solve the problem. The problem was, "How can I code an e-commerce site that uses any database while decoupling logic from presentation?" The problem also encompassed the question, "How can I do this easily?" And the problem also contained, "How can it be state-driven?" > p.s. I don't think you will get far with an argument about being coupled to > Java as being negative around here. A fair number of years ago people would have said the same thing about ANSI C. SGML has been around (at least conceptually), as I've mentioned, since the late 1960s. XML serves as a wonderful mechanism for information interchange--and has 30 years of development behind it. C had a fabulous run of popularity (Perl, Java, and C++ are slowly replacing it). I don't see how presuming the possibility of Java fading away is an invalid argument. Moreover, I cannot see how safeguarding against coupling yourself to ANY programming language is bad. Unless you possess a crystal ball, please don't tell me Java is going to be around forever. Does that mean Java isn't a good technology? Heck no. Does it mean we should avoid Java? Heck no. Every type of technology has its place -- what you need to do is look at the PROBLEM and figure out what technologies form a robust solution. Java is not meant to be THE technology for ALL problems. Once again, I am, sincerely yours, Dave Jarvis -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
