I can see I'm going to have to go back to this again.

Post #12,707 by admin 10/10/01 3:54:25 PM Reply	I can see I'm going to have to go back to this again. Since you're ignoring questions. Businesses want remote GUI's that are network-friendly. HTML is great for brochure-like content, but NOT data-intensive interactive biz apps. What the hell do you call an interactive bond trading application, if not a "data-intensive interactive biz app"?? Regards, -scott anderson
Post #12,805 by tablizer 10/10/01 10:50:27 PM Reply	This is not an OO battle.......yet The "biz app" thing is related to anti-OO battles, not necessarily SCGUI battles. You are getting your battles mixes up I believe. Nepolean is not at Perl Harbor. BTW, my tablized version of the report framework thingy is at: [link\|http://geocities.com/tablizer/chal06.htm\| [link\|http://geocities.com/tablizer/chal06.htm\|http://geocities.co...r/chal06.htm]] if you want to do some OO battle. I suggest you take any report comments to EZboard because Scott does not want to clutter this forum with anti-OO battles. Wait.....you ARE scott. How polymorphic. ________________ oop.ismad.com
Post #12,834 by static 10/11/01 12:47:18 AM Reply	I think I'd give up, Bryce. At least in this battle. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #12,869 by admin 10/11/01 10:06:43 AM Reply	Funny... I could have sworn you said: "Businesses want remote GUI's that are network-friendly. HTML is great for brochure-like content, but NOT data-intensive interactive biz apps." Why yes, yes you did indeed say that, right [link\|http://z.iwethey.org/forums/render/content/show?contentid=12437\|here]. Strangely enough, you're right. This isn't about OO battles. However, you said "HTML is great for brochure-like content, but NOT data-intensive interactive biz apps" (there it is again) to which I asked, "What the hell do you think an online bond trading application is, if not a data-intensive interactive biz app"? Regards, -scott anderson
Post #12,924 by tablizer 10/11/01 2:00:52 PM Reply	"doable" is not the criteria I am using. >> I could have sworn you said: "Businesses want remote GUI's that are network-friendly. HTML is great for brochure-like content, but NOT data-intensive interactive biz apps." << Okay. Notice the phrase "great for". Yes, you can **do** stuff in HTML and DOM and JavaScript, but that does not make it the ideal solution. Like I said in the other thread, I keep seeing a need for SCGUI-like standards in biz stuff. Whether your bond stuff would serve as a poster-child for SCGUI or not is moot. It is one app out of jillions. I am talking in general here. ________________ oop.ismad.com
Post #12,971 by admin 10/11/01 4:02:25 PM Reply	ROFL Twist, turn... every time someone comes up with Yet Another Business App That Doesn't Fit Bryce's Preconceptions, you move the goalposts again. Have you ever done DOM/Javascript programming? No? Yet you feel qualified to talk about what it is and isn't capable of doing? Regards, -scott anderson
Post #13,206 by tablizer 10/12/01 9:37:20 PM Reply	not GUI. QED >> ....you move the goalposts again. << I didn't move anything. I don't know your company and what their obsticles are WRT SCGUI. I have to take your arrogant word for it. IOW, I can't get a second opinion (outside of the speed issue). >> Have you ever done DOM/Javascript programming? No? Yet you feel qualified to talk about what it is and isn't capable of doing? << Are you saying that DOM + Javascript is the best UI approach for all or most applications that would work better as a GUI? Ignoring existing browser standards for the moment, do you truly think that the current browser model is the ideal interface for B-to-B and intranets? BTW, how do you know if/when DOM or JS crashes/abends in a browser? ________________ oop.ismad.com
Post #13,225 by pwhysall 10/14/01 5:36:01 AM 10/14/01 6:36:05 AM Reply	Nothing like answering the question, eh? " >> Have you ever done DOM/Javascript programming? No? Yet you feel qualified to talk about what it is and isn't capable of doing? << Are you saying that DOM + Javascript is the best UI approach for all or most applications that would work better as a GUI? Ignoring existing browser standards for the moment, do you truly think that the current browser model is the ideal interface for B-to-B and intranets? BTW, how do you know if/when DOM or JS crashes/abends in a browser?" Well, have you or have you not done DOM/Javascript? BTW, this conversation brings to mind the Black Knight ("It's only a flesh wound!" "But your arm's off!" "No it isn't!")... Sigh... Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal] Edited by pwhysall Oct. 14, 2001, 06:36:05 AM EDT Expand All History
Post #13,236 by tablizer 10/14/01 3:23:37 PM Reply	and you did NOT answer my question "do you truly think that the current browser model is the ideal interface for B-to-B and intranets?" Why should I answer your questions if you don't answer mine? ________________ oop.ismad.com
Post #13,238 by pwhysall 10/14/01 3:30:24 PM Reply	Because... ...it's usual form to answer the question put, (have you used Javascript/DOM) with an answer, not another question. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,301 by admin 10/15/01 9:53:24 AM Reply	Ideal? No. Better than SCGUI? Yes. 1) What happens when there's some new bit of functionality that I need in my app that SCGUI doesn't support? We wait for the entire world to upgrade? vs. A generic programming interface (Javascript) and GUI model (DOM) that supports everything that needs to be done now. SCGUI loses. 2) What is on 90+% of the desktops now? SCGUI? No. DOM + Javascript? Yes. Clients need not install anything new, configure anything new, nor understant anything new to run a DOM/JS app. SCGUI loses. 3) Does DOM/JS support everything I need to do now, and is it likely to be able to support everything I do in the future? Since DOM/JS was designed for client-side applications running in browsers, the answer is yes. SCGUI, the new, untested, unproven, unheard of, unneeded "protocol", loses. WRT DOM/JS crashing, the server-side component detects that the socket connection is severed. Regards, -scott anderson
Post #13,361 by tablizer 10/15/01 1:36:57 PM Reply	HTML + DOM + JS is a fricken mess >> What happens when there's some new bit of functionality that I need in my app that SCGUI doesn't support? We wait for the entire world to upgrade? vs. A generic programming interface (Javascript) and GUI model (DOM) that supports everything that needs to be done now. << You are assuming that JS+DUM can handle every new requirement and that SCGUI can't. This assumption has not been verified. >> SCGUI, the new, untested, unproven, unheard of, unneeded "protocol", loses. << So we stick with the gummy mix of multiple protocols and crashing JS that has ended up in current browsers, or do we look at remote biz GUI requirements and make something optimized for them instead of the overly-bent HTML-dirived protocols? You: "Fortran + Cobol are good enough and in common use, why move on?" ________________ oop.ismad.com
Post #13,369 by pwhysall 10/15/01 1:42:40 PM Reply	A little challenge Identify ONE real-world application that's actually out there that would be heaps better if it was re-written in SCGUI. Things to consider are portability, deployment, scalability, amongst others. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,490 by tablizer 10/16/01 1:31:47 AM Reply	user interface >> Identify ONE real-world application that's actually out there that would be heaps better if it was re-written in SCGUI. << Since I deal with custom applications, I don't think I could name one that anybody has seen. Look at this way. Look at your favorite typical client-server biz application made with VB, Powerbuiler, Delphi, etc. Do you think they would be more usable if they were an HTML app or an HTML+JS+DOM app instead of the way they are? (Assuming you don't pick one that sucks because the designers are idiots.) ________________ oop.ismad.com
Post #13,515 by pwhysall 10/16/01 3:03:35 AM Reply	Re: user interface In other words, you can't. "Since I deal with custom applications" is a cop-out, and you know it. If you can't find one single released application done in JS/DOM that you're going to port to SCGUI and have me run it (my test platform is Linux, BTW) then you lose. But you'll give me a "custom biz app" (i.e. Yet Another Purchase Order System, I'll bet)... Ya right. Bryce, yer all mouth and no trousers. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,609 by tablizer 10/16/01 2:42:42 PM 10/16/01 2:44:02 PM Reply	Because nobody wants to use that crap for GUI's >> If you can't find one single released application done in JS/DOM that you're going to port to SCGUI and have me run it << I can't find such a beast because people rarely do full GUI's with JS+DOM. Further, I focus on custom biz apps, NOT "released" apps. That is NOT what SCGUI targets. You are asking for something that SCGUI does not even compete against for the most part. Your request is circular. My SCGUI project is avialable for all to download and play with (and add to). Where is your side's? I see nothing but talk. If it is proprietary and thus cannot be released, too bad. That is more points for mine: 1. Open standard 2. Free demo with source code 3. One protocol instead of three ________________ oop.ismad.com Edited by tablizer Oct. 16, 2001, 02:44:02 PM EDT Expand All History
Post #13,611 by pwhysall 10/16/01 2:48:40 PM Reply	Re: Because nobody wants to use that crap for GUI's My SCGUI project is avialable for all to download and play with (and add to). Where is your side's? I see nothing but talk. For all? Erm, did MS port VB to Linux when I wasn't looking or something? That is more points for mine: 1. Open standard 2. Free demo with source code 3. One protocol instead of three I'll give you (2) - even though I can't run the thing. You're bullshitting on (1), because SCGUI isn't a standard. Not even close. Just because you release a bit of code doesn't make it a standard. (3) is bollocks, and well you know it. You're using at least two "protocols" (sigh, programming languages aren't protocols, but WTFever) - SCGUI, and your transport protocol, TCP/IP. Really, you're using 3, because of the VB protocol you're making me use. Oops. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,613 by pwhysall 10/16/01 2:51:32 PM Reply	Forgot one. SCGUI runs over HTTP, right? Which is an actual, can't-get-better-than-the-real-thing protocol. That makes 4. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,709 by tablizer 10/16/01 11:38:32 PM Reply	sloppy counting >> TCP/IP. Really, you're using 3, because of the VB protocol you're making me use. Oops. << TCP/IP and/or HTTP are a given in both because some protocol needs to message the stuff back and forth. The VB is on the server side. Scott's solution will also have server-side languages, which I did not count. I also did not count the browser, which I assume that the developer will not have to diddle with under normal circumstances. Regardless, if you count properly, you still get x < x + 1 or x < x + 2 if Scott uses HTML. ________________ oop.ismad.com
Post #13,370 by pwhysall 10/15/01 1:43:12 PM Reply	A little challenge Identify ONE real-world application that's actually out there that would be heaps better if it was re-written in SCGUI. Things to consider are portability, deployment, scalability, amongst others. Hell, be a man. Port the damn thing. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,373 by admin 10/15/01 1:48:10 PM Reply	Re: HTML + DOM + JS is a fricken mess You are assuming that JS+DUM can handle every new requirement and that SCGUI can't. This assumption has not been verified. And you are asserting that DOM/JS cannot handle any requirement, despite the fact that I used them to easily do exactly the same sorts of things you claim that SCGUI is required to do. So we stick with the gummy mix of multiple protocols and crashing JS that has ended up in current browsers, or do we look at remote biz GUI requirements and make something optimized for them instead of the overly-bent HTML-dirived protocols? Or do we perhaps do some actual design and architecture using the currently available, proven tools, and actually create a usable solution instead of attempting to (once again) rewrite the wheel? You: "Fortran + Cobol are good enough and in common use, why move on?" One word: XBASE. Don't throw stones, unless you've already located a good real estate agent to find a new glass house. Change is only good when there is a need. Fortran and Cobol have serious limitations in certain areas. You have not demonstrated that DOM/JS has the limitations you claim to be surmounting with SCGUI. Regards, -scott anderson
Post #13,710 by tablizer 10/16/01 11:52:44 PM Reply	starting a new road when traffic is sufficiently high >> that I used them to easily do exactly the same sorts of things you claim that SCGUI is required to do.......Change is only good when there is a need. << I never said "required". Anyhow, the crux of the problem comes down to: 1. Is the need for remote GUI's common 2. Are existing tools/protocols sufficient to address #1 If a need is not common, then a "good enough" solution is often sufficient. However, IMO #1 is high. Thus, the industry needs something dedidated to that task. Nobody here seems to want to claim that JS+DOM is near an OPTIMUM remote GUI solution. Thus, there seems to be an implicit admission that JS+DOM is not the ideal for remote GUI's. Our difference seems to hover around #1, the frequency of need. In a good many B-to-B and intranet projects I dealt with, management keeps wanting the browser to be "regular" GUI. The arrow just keeps pointing back that way. They want data grids, dialog boxes, pop-up error messages, menu bars, etc. The need is plenty high enough to warrent protocols dedicated to that task. ________________ oop.ismad.com
Post #13,731 by admin 10/17/01 9:27:29 AM Reply	Re: starting a new road when traffic is sufficiently high 1. Is the need for remote GUI's common Yes. 2. Are existing tools/protocols sufficient to address #1 Yes. Regards, -scott anderson
Post #13,821 by tablizer 10/17/01 4:19:24 PM Reply	I have to disagree with your #2 response ________________ oop.ismad.com
Post #13,939 by CRConrad 10/18/01 8:23:34 AM Reply	No, you don't "have to". You just do so anyway. For no better reason than that you're stupid and obstinate, as far as I can see. Christian R. Conrad The Man Who Knows Fucking Everything

Welcome to IWETHEY!