Ideal? No. Better than SCGUI? Yes.

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!