Re: security risks

Post #13,226 by pwhysall 10/14/01 5:37:59 AM Reply	Re: security risks >Downloaded exec/scripts: >1. Complicate the browser design No they don't because the functionality you're using is already in the browser. Plus, you get to leave a whole bunch of stuff to the browser writers. And funnily enough, I think that IE6 and Mozilla are somewhat better than your half-assed SCGUI "thing", which is - gasp - a browser. >2. Increase versioning problems No it doesn't; in fact, it makes it easier because the only (released) version you have to keep in sync is on the web server. >3. Create security risks Such as? How'd you know this whole shooting match isn't running over a VPN tunnel? >4. Increase download times Compared to what? >5. More things to crash Compared to what? Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,235 by tablizer 10/14/01 3:21:04 PM Reply	Turing-complete == more-problems-complete >> [Complicate the browser design] No they don't because the functionality you're using is already in the browser. Plus, you get to leave a whole bunch of stuff to the browser writers. << But it complicates the browser. A browser that only chomps "static" commands is going to be less complicated and have less problems and less security risks than one that chomps Turing-complete commands. >> No it doesn't; in fact, it makes it easier because the only (released) version you have to keep in sync is on the web server. << Huh? >> [Increase download times] Compared to what? << Not downloading code. I will agree that it may exchange an up-front wait for smaller, incrimental waits in some cases. But remember that SCGUI has asynchonous "send" options. Thus, the server can be checking stuff in-between "submits". >> [More things to crash] Compared to what? << A non-turing-complete protocol. ________________ oop.ismad.com
Post #13,237 by pwhysall 10/14/01 3:28:33 PM Reply	Re: Turing-complete == more-problems-complete >> [Complicate the browser design] No they don't because the functionality you're using is already in the browser. Plus, you get to leave a whole bunch of stuff to the browser writers. << But it complicates the browser. A browser that only chomps "static" commands is going to be less complicated and have less problems and less security risks than one that chomps Turing-complete commands. It only complicates the browser for you because you have to write the damn thing. A browser that supports Javascript and the DOM is code that someone else has written, tested and released. (I'd love to know what being Turing-complete has to do with it.) As I said, you don't know the nature of the connection; I expect, that as this is a commercially sensitive system, that all communications links are encrypted and are likely NOT on the internet anyhow. >> [Increase download times] Compared to what? << Not downloading code. I will agree that it may exchange an up-front wait for smaller, incrimental waits in some cases. But remember that SCGUI has asynchonous "send" options. Thus, the server can be checking stuff in-between "submits". And you've determined this in tests by implementing the same functionality in Javascript and SCGUI, right? No? Didn't think so. If your SCGUI thing sends a shitload of XML (and all the XML things I've ever seen (Jabber, frinstance) are nothing if not verbose) down the pipe, what's the difference between that and an HTML page with script? >> [More things to crash] Compared to what? << A non-turing-complete protocol. Such as? Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,358 by tablizer 10/15/01 1:26:41 PM Reply	Using 3 protocols is just plain silly, admit it! >> It only complicates the browser for you because you have to write the damn thing. << I am not sure what you mean here. >> A browser that supports Javascript and the DOM is code that someone else has written, tested and released. (I'd love to know what being Turing-complete has to do with it.) << JavaScript and DHTML are common reasons for browser bugs and lock-ups IME. Perhaps in some cases one can dictate only certain browser versions and brands to reduce that risk, but that is often not the case. Further, HTML + JS + DOM is three different protocols. Wouldn't it be nice to only have to use one protocol instead of 3? Or should we stick with such silliness forever? It is a common enuf need in biz to address it head-on and get a real protocol for remote GUI's instead of dance around with 3 clutsy dance partners. >> If your SCGUI thing sends a shitload of XML (and all the XML things I've ever seen (Jabber, frinstance) are nothing if not verbose) down the pipe, what's the difference between that and an HTML page with script? << I have answered this already for you. SCGUI is delta-based: you only send what changes. In HTML, you have to send an ENTIRE new page or frame even if you want to change one little thing. If you want a red error message next to a textbox, you only send the code to place the error text in SCGUI. In HTML you have to re-send the entire page. Besides, SCGUI is position-based instead of flow-based. (The server can work in flows if needed and translate it to coordinates.) HTML has no usable coordinate mode because you don't know where things are going to end up on each client. (You can use DHTML, but this has its own problems, plus, then you are dealing with FOUR protocols. It is like String Theory: with enough dimensions thrown in, you can explain anything you want, real or imagined. However, you end up with a complex wod of string, which is what browser programming has become.) >> I'd love to know what being Turing-complete has to do with it. << A full-blown language has more potential for bugs because you have a more complex protocol to have to get right and keep upgrading, and more combinations that can do unpredictable things. ________________ oop.ismad.com
Post #13,362 by admin 10/15/01 1:38:17 PM Reply	Patently false: DHTML is not the same as DOM JavaScript and DHTML are common reasons for browser bugs and lock-ups IME. Perhaps in some cases one can dictate only certain browser versions and brands to reduce that risk, but that is often not the case. DHTML is not the same as DOM. The JS/DOM code I wrote works in Mozilla, Netscape 6, and IE 5.X+ with absolutely no browser-specific code whatsoever. Regards, -scott anderson
Post #13,374 by tablizer 10/15/01 1:48:48 PM Reply	I did not say it was >> DHTML is not the same as DOM << Even if by some miracle it is less buggy than DHTML, JS is always croaking when I do stuff on the web. Even big names like Yahoo have crashing JS. ________________ oop.ismad.com
Post #13,380 by admin 10/15/01 1:58:11 PM Reply	JS/DOM is not the same as DHTML. So quit using your experience in DHTML as your excuse to bash DOM. They aren't the same. I've left my realtime update scripts running overnight at a rate of 200 updates per second, without crashing and without any problems. Regards, -scott anderson
Post #13,363 by admin 10/15/01 1:38:44 PM Reply	Patently false: three different protocols Further, HTML + JS + DOM is three different protocols. Wouldn't it be nice to only have to use one protocol instead of 3? Or should we stick with such silliness forever? It is a common enuf need in biz to address it head-on and get a real protocol for remote GUI's instead of dance around with 3 clutsy dance partners. Not necessary. The DOM/JS library I have written requires absolutely no knowledge of DOM or JS for the HTML coder. Regards, -scott anderson
Post #13,376 by tablizer 10/15/01 1:50:31 PM Reply	How does that make any difference? Browser still deals w/ 3 ________________ oop.ismad.com
Post #13,382 by admin 10/15/01 1:59:23 PM Reply	How does that make any difference? Developer still deals w/1 Regards, -scott anderson
Post #13,706 by tablizer 10/16/01 11:20:03 PM Reply	NOPE, 2 You still have 2 languages/protocols that have to be dealt with: JS and DOM. Your JS library is not open source, so any company that wants to roughly recreate your setup has to program in 2 languages. Just because it may not be the same programmer doing each does not change the fact that 2 languages are needed. ________________ oop.ismad.com
Post #13,730 by admin 10/17/01 9:24:50 AM Reply	Same in SCGUI. Server side language and SCGUI itself. So what's the difference? Regards, -scott anderson
Post #13,822 by tablizer 10/17/01 4:23:03 PM Reply	odd counting SCGUI solution: 1. Server-side language 2. SCGUI protocol YOUR SOLUTION 1. Server-side language 2. JS 3. DOM 4. HTML? ________________ oop.ismad.com
Post #13,847 by admin 10/17/01 6:18:59 PM Reply	Re: odd counting - yes, you do count oddly. SCGUI solution: SCGUI browser download/installation - developer doesn't need to know implementation to use SCGUI server side code Mine: JS download - developer doesn't need to know JS to use HTML server side code Bur of course, you will never ever admit that the developer doesn't need to know JS in my solution, so until then, have a good life. Regards, -scott anderson
Post #13,904 by tablizer 10/18/01 12:51:13 AM Reply	assumption missing >> SCGUI browser download/installation << But you are not counting Netscape download and installion. I am assuming that SCGUI (or something like it) becomes common. I realize for your particular situation, that is not a realistic assumption. But, I am thinking macro here. >> But of course, you will never ever admit that the developer doesn't need to know JS in my solution, << You divided up the labor so that one programmer makes some libraries and another uses those libraries. You did not eliminate JS programming by relabling it "generic". If they became public domain or OSS and fairly common, then I might count it differently. You probably say the same thing about SCGUI. However, at least I have a public demo whereas you don't. I just think the industry needs a good remote GUI protocol, and your approach is not it. That is all I am saying. ________________ oop.ismad.com
Post #13,919 by pwhysall 10/18/01 2:56:45 AM Reply	That's even nuttier for you Because SCGUI only runs on a platform that ships with an integrated web browser that's fully kitted out with JavaScript and the DOM. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,922 by pwhysall 10/18/01 3:07:05 AM Reply	Clarification What I mean is that you're bitching about having to download and install Netscape (why? Every Linux distro out there COMES with the damn thing)... Windows comes with IE5, which is all-singing, all-dancing JS/DOM stylee. You have to download and install the SCGUI "browser". JS/DOM = no effort for user, just go to web page SCGUI = Muchas effort for user, including installing spawn-of-satan VB runtime libraries. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,921 by pwhysall 10/18/01 3:00:53 AM Reply	Re: assumption missing I just think the industry needs a good* remote GUI protocol, and your approach is not it. That is all I am saying.* Cross platform, check. Application-independent, check. Low bandwidth, check. Low latency, check. [link\|http://www.citrix.com\|Click Here] You really don't know ANYTHING about this area, do you? Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #14,103 by tablizer 10/19/01 12:47:16 AM Reply	Cytrix is NOT latency-friendly, and.... I have never seen it run over HTTP. Have you? ________________ oop.ismad.com
Post #14,125 by pwhysall 10/19/01 3:18:56 AM Reply	Yes it bloody well is! It runs over links as slow as a 28.8k modem! It's extremely "latency-friendly". (I think you really mean "low latency" as in "interactive but what the hey. It's too late to expect you to start making sense now) Gah, you really know nothing at all about it. And why would I care if it runs over HTTP? Yeah, running a binary protocol (Citrix ICA) over a textual one (HTTP). Uh huh. Yeah. Pass me the crack pipe when you're done. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #14,264 by tablizer 10/20/01 2:42:11 AM Reply	HTTP is important >> And why would I care if it runs over HTTP? << Because HTTP is choppier than other protocols (that may work over an 28.8 modem). Often corporate firewalls only work with HTTP, and the admins don't like exceptions. I have seen it happen multiple times. Tell me that Cytrix works fine over a modem using HTTP. ________________ oop.ismad.com
Post #14,274 by pwhysall 10/20/01 4:52:02 AM Reply	Bollocks Now you're a network admin? You're seriously telling me that corporate networks don't allow Citrix ICA traffic through - as a matter of policy? looks at his corporate firewall Well, MY firewall lets it through. Firewall-1 even has a predefined port range, just tick the "Citrix" box and make a rule. You're blowing hot air. You know nothing about Citrix products and you know nothing about corporate network administration (which is what I do for a living, you numbskull). Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #14,316 by tablizer 10/20/01 2:43:55 PM Reply	I saw it happen >> You're seriously telling me that corporate networks don't allow Citrix ICA traffic through - as a matter of policy? << Here is the deal. I contracted at a place that sent sales leads to hundreds of businesses. They used VB with Cytrix. Enough of those 100+ "consumers" of the data complained that either their firewall would not let the information through, or they did not have the staff to troubleshoot/change/approve the firewall problems. (Some customers were big and some were small.) It was a big enough complaint that the data distributor (the place I contracted at) decided to make a web-based version using Java. (Coordinating Java certs was a major pain, and was not yet fully solved by that developer when my stint was up. They used Java because they wanted a decent grid and HTML didn't give it. But that is another story. Personally IMO they didn't think it through enough.) The customer is always right and enuf customers complained about Cytrix and the firewalls. ________________ oop.ismad.com
Post #14,319 by bepatient 10/20/01 2:49:47 PM Reply	Get a room guys... You were born...and so you're free...so Happy Birthday! _{Laurie Anderson} [link\|mailto:bepatient@aol.com\|BePatient]
Post #14,322 by pwhysall 10/20/01 3:09:14 PM Reply	And that proves what? That some people don't see a business benefit for using Citrix products? You, as a contractor, know precisely bugger all about the reasoning behind the rejection of Citrix products as a solution. Get real. The fact that some of these clients were small leads me to think that it was primarily rejected on cost grounds. It's feary expensive stuff. Small clients also see the cost and go "no, we're not modifying our budget plans^W^Wfirewall for that". If there's a business need for poking a hole in the firewall, it will be done. no amount of raving that you do will change that. Remember, Microsoft recently bought one of the most popular accounting packages, Great Plains - this is one of the most common ICA applications. There's a remote GUI solution that kicks SCGUI's ass off the map. It's called Java. Or it's called JavaScript. Take your pick, SCGUI does NOT solve any problems. YOU can't throw a VB app onto my Linux computer. Citrix Metaframe can do that. Until you can run your SCGUI thing on more than one platform, you're just not in Metaframe's league. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #14,323 by pwhysall 10/20/01 3:13:17 PM Reply	One last thing I've finally grown tired of trying to impart clues to you. That was my last post on the subject - it's quite clear you're not interesting in learning anything, only arguing. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #14,373 by ben_tilly 10/21/01 2:14:16 AM Reply	Actually Bryce has a point here The fact that your corporate network allows Citrix through doesn't mean that all of them do. In fact many do not. As you well know, well-run firewalls start out with a default "deny all". And then you start adding things you allow. If they don't have an exception made for Citrix traffic from outside, you won't get it without a bureaucratic hassle. And at many companies the corporate firewall kills Citrix. If you want to deliver a product over the net using Citrix, you will lose potential clients because of that. It is no fun calling up a prospect and finding that the group you are dealing with don't receive Citrix. You may have a perfectly good product. But you can't demo it to them. And even if you did sell them on how nice your stuff is, they won't bother because they don't have the time or energy convincing their BOFHs that they really need this. (And yes, the company where I work looked long and hard at trying to deliver products to clients using Citrix. And for our client base it wasn't worthwhile. We, in fact, get better penetration of our core market from our Bloomberg product than we could get with Citrix. That should tell you a lot about who our clients are.) Cheers, Ben
Post #14,421 by static 10/21/01 9:10:27 AM Reply	But I'm wondering how relevant it is. Scott's application was IIRC for a private network. Such a scenario would be unlikely to have firewalls restricting traffic. And if it did, they would be more likely to be configured to let the appropriate traffic through. But you're right; Bryce does have a valid point about sending that stuff over the 'net. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #14,526 by ben_tilly 10/22/01 8:14:12 AM Reply	It is at least halfway There are people who sell things like the application under question. So whether or not it is for public sale, the concerns of publically selling it are not irrelevant for applications like that. Furthermore even if it is private, as a developer Scott may face IS barriers if he wants to modify current network policy and use Citrix. Again, if they have Citrix, it isn't an issue. If not, then it could be. Which is, of course, irrelevant since he delivered through HTTP. :-) Cheers, Ben
Post #14,574 by addison 10/22/01 12:54:48 PM Reply	Not quite irrelevent... Which is, of course, irrelevant since he delivered through HTTP. :-) The current crop of firewalls are (for just this purpose) able to look into packets and ensure that they are HTTP packets.. Packets that look to be encapsulated other protocols can be rejected, or filtered. So if you're 'denying all' you've likely got that [passing of HTML encapsulated packets] turned off, too. Addison
Post #13,365 by admin 10/15/01 1:39:46 PM Reply	Patently false: HTML/DOM/JS requires full page reloads I have answered this already for you. SCGUI is delta-based: you only send what changes. In HTML, you have to send an ENTIRE new page or frame even if you want to change one little thing. If you want a red error message next to a textbox, you only send the code to place the error text in SCGUI. In HTML you have to re-send the entire page. Wrong. The DOM/JS library I have written was designed specifically to alleviate this need. Only changes are sent. Regards, -scott anderson
Post #13,377 by tablizer 10/15/01 1:54:25 PM Reply	Sorry, I misread it. He asked: "what's the difference between that and an HTML page with script?" I missed the "with script" portion. Sorry. Note, however, that it takes 2+ protocols to pull that off. SCGUI only needs one. ________________ oop.ismad.com
Post #13,383 by admin 10/15/01 2:00:27 PM Reply	Once again: strawman alert The developer is only dealing with one. Whatever happened to "let the compiler deal with it"? If the developer doesn't have to deal with the DOM/JS, what difference does it make? Regards, -scott anderson
Post #13,387 by tablizer 10/15/01 2:20:52 PM Reply	so you say >> If the developer doesn't have to deal with the DOM/JS, what difference does it make? << You don't know this, it is only a few weeks old. When you go live, you may have browsers crashing and flaking left and right. Besides, even if your approach happened to work with this particular application (I can'T verify your jabber), that does not mean that it is the ideal approach to every B-to-B and and intranet application. (If your library gets big enough, it might turn out to resemble a SCGUI browser plug in. You may be growing closer to SCGUI without even realizing it. However, people outside your company will be re-inventing such wheels over and over.) ________________ oop.ismad.com
Post #13,388 by admin 10/15/01 2:28:18 PM 10/15/01 2:30:05 PM Reply	Re: so you say You don't know this, it is only a few weeks old. When you go live, you may have browsers crashing and flaking left and right. Er, no, we DO know this, because we did a lot of testing, as I mentioned elsewhere. Odd thing, that... when you actually sit down and design something, and test it, generally you don't have sudden problems in the field. Besides, even if your approach happened to work with this particular application (I can'T verify your jabber), that does not mean that it is the ideal approach to every B-to-B and and intranet application. And? Have you tried DOM/JS with any applications you claim it can't work with? No? Then you can't make that assertion either. (If your library gets big enough, it might turn out to resemble a SCGUI browser plug in. You may be growing closer to SCGUI without even realizing it. However, people outside your company will be re-inventing such wheels over and over.) Imagine that. We've come round full circle. I remember telling you a long time ago that there isn't anything you can't do with DOM/JS that SCGUI is intended to fix, and you just confirmed the possibility. As far as reinventing the wheel goes, you're one to talk, Mr. I Have A "Browser" That Completely Reinvents Everything Done Over The Past 8 Years On The Internet For No Good Reason. SCGUI is just another iteration of the whole 3270/5250 wheel. Regards, -scott anderson Edited by admin Oct. 15, 2001, 02:30:05 PM EDT Expand All History
Post #13,366 by pwhysall 10/15/01 1:39:56 PM Reply	Only one protocol in use And that's HTTP. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,379 by tablizer 10/15/01 1:56:52 PM Reply	wrapping is not ridding >> Only one protocol in use And that's HTTP. << That is misleading. HTTP is more a transport protocol. That is like saying, "it is all only the binary protocol, because it all goes over in 1's and zeros." ________________ oop.ismad.com
Post #13,381 by pwhysall 10/15/01 1:59:15 PM Reply	Well I never And here's me thinking the DOM is an API and Javascript a programming language that uses said API. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,367 by admin 10/15/01 1:40:27 PM Reply	Patently false: SCGUI is immune to versioning problems Besides, SCGUI is position-based instead of flow-based. (The server can work in flows if needed and translate it to coordinates.) HTML has no usable coordinate mode because you don't know where things are going to end up on each client. (You can use DHTML, but this has its own problems, plus, then you are dealing with FOUR protocols. It is like String Theory: with enough dimensions thrown in, you can explain anything you want, real or imagined. However, you end up with a complex wod of string, which is what browser programming has become.) And when people start identifying needs that aren't met by SCGUI? You'll start adding them, one at a time, and eventually you'll be right back in the same position. Regards, -scott anderson
Post #13,384 by tablizer 10/15/01 2:12:34 PM Reply	dancing widgets I never said 100 percent immune from versioning. You are putting words in my mouth. Knock it off. >> And when people start identifying needs that aren't met by SCGUI? You'll start adding them, one at a time, and eventually you'll be right back in the same position. << Less != Zero I beleive in the concept of moving as much of the complexity to the server as possible. I don't claim that a SCGUI browser will NEVER need upgrading, but simply that it would be needed LESS often because it does not have to interpret full-blown programming languages and combinations of goofy protocols. Besides, if the communication packets can move at movie speed, then the coordinate graphics of SCGUI could create and animate just about anything you can envision on the screen. (In Malraux's case, it seems to be just text-box updates, so graphics are not an issue here.) Any widget or gizmo can be drawn and animated if the speed is high enough. (I did not really intend this, but it is possible if the communication turnaround is fast enuf.) For example, you could make a tree-browser without sending a "tree-widget" DLL or library. The server simply sends the lines and text to make up the tree. When you click on or roll over a line or text item in the tree diagram, SCGUI can (optionally) send this information to the server, which then decides if it wants to move or change the tree diagram as needed. ________________ oop.ismad.com
Post #13,385 by admin 10/15/01 2:17:39 PM Reply	SCGUI: moving the complexity to the server. No, you didn't, but you're claiming that it is better than downloadable libraries for versioning, which is patently false. So what is the server-side stuff written in? SCGUI? If not, then all of a sudden you've got (gasp) more than one "protocol" (which seems to be a Brycian word for "API/language/anythingelsehethinksisbad". Regards, -scott anderson
Post #13,390 by tablizer 10/15/01 2:30:25 PM Reply	VB, Delphi, Powerbuilder, etc. >> No, you didn't, but you're claiming that it is better than downloadable libraries for versioning, which is patently false. << See my other message about creating a virtual SCGUI browser via libraries. >> So what is the server-side stuff written in? SCGUI? If not, then all of a sudden you've got (gasp) more than one "protocol" (which seems to be a Brycian word for "API/language/anythingelsehethinksisbad". << What protocol are you using to instantly update your DOM textboxes? Home-brew, probably. How is that better than SCGUI? Anyhow, ideally one would use a regular GUI IDE to develope their GUI's. No need for knowledge of SCGUI specifically any more than one has to know Windows GUI API's. You would simply whip out your fav GUI IDE tools, like VB, Delphi, etc., make the application, then specify "SCGUI" in some "target platform" property box. It would be just like developing client/server applications, except that it runs on an internet server instead. ________________ oop.ismad.com
Post #13,393 by admin 10/15/01 2:37:37 PM Reply	Once again, where is the value-add? You're not making a very good case for creating a brand-new architecture by pointing out how much like existing stuff it is. See my other message about creating a virtual SCGUI browser via libraries. And how is that better/different than the existing browsers that download libraries? Which, incidentally, are already working and installed on everyone's desktop... What protocol are you using to instantly update your DOM textboxes? Home-brew, probably. How is that better than SCGUI? It's already running on everyone's desktop, and it uses existing tools without reinventing the wheel. As I said, implementing SCGUI in DOM/JS would be relatively straightforward, but there's no value-add there. What you haven't answered is "how is SCGUI better than the existing tools". Anyhow, ideally one would use a regular GUI IDE to develope their GUI's. No need for knowledge of SCGUI specifically any more than one has to know Windows GUI API's. You would simply whip out your fav GUI IDE tools, like VB, Delphi, etc., make the application, then specify "SCGUI" in some "target platform" property box. It would be just like developing client/server applications, except that it runs on an internet server instead. Fine, as long as you admit that this is another "protocol" that the developer needs to know, no different than all the other stuff that is already out there. You're not "creating" anything new or needed here. Regards, -scott anderson
Post #13,482 by tablizer 10/16/01 12:06:28 AM Reply	same arguments over and over >> You're not making a very good case for creating a brand-new architecture by pointing out how much like existing stuff it is. << I am not sure what you mean here. People want GUI's for their web biz apps. >> It's already running on everyone's desktop, and it uses existing tools without reinventing the wheel. << Still a variation of "why not just use Fortran or COBOL instead of another language?" >> What you haven't answered is "how is SCGUI better than the existing tools". << Does JS+DOM make a decent "normal" GUI interface? I still say the need for remote GUI's is common enough to justify a dedicated protocol. JS+DOM is just a short-term wannabe WRT GUI's. ________________ oop.ismad.com
Post #13,555 by admin 10/16/01 9:35:03 AM Reply	I'll agree with that. Since you aren't answering the questions sufficiently. 1) Yes, people want GUIs. With HTML, DOM, and JS they get GUIs. 2) And your argument is just a variation on "it's 'new' so it must be better". Fortran and COBOL were replaced because SOMETHING BETTER came along, not just SOMETHING DIFFERENT. And what you are proposing isn't even that different. You're advocating a return to something that has ALREADY been replaced because it was insufficient. As soon as you get past that, we'll talk again. Until then you're just being boring. Regards, -scott anderson
Post #13,607 by tablizer 10/16/01 2:33:36 PM Reply	So at least you agree that they want GUI's >> Yes, people want GUIs. With HTML, DOM, and JS they get GUIs. << You agree that they want GUI's. But, HTML+DOM+JS is clearly not the ideal way in the long run. For one, it is 3 protocols instead of one. I doubt a library would handle all the typical GUI needs without a lot of diddle daddle. I think if 100 study groups set out to define a remote GUI protocol without worrying about existing browser "standards" (cough cough), very few of the results would look like HTML+DOM+JS. You are just stuck in narrow ways of thinking. You are great at learning languages, but poor at defending them. IOW, you are fast at learning dumb ways to do things IMO. >> You're advocating a return to something that has ALREADY been replaced because it was insufficient. << Could you elaberate on the specific "insufficiencies"? You arguments are like, "It is no good because it is bad." I gave examples of SCGUI protocol calls, now how about you show examples of your Great GUI Protocol? Are you too ashamed to show them? Your K.I.S.S. ate a lemon? ________________ oop.ismad.com
Post #13,608 by pwhysall 10/16/01 2:39:30 PM Reply	Re: So at least you agree that they want GUI's "I doubt..." "I think..." Howsabout bringing some knowledge to the table. You're asserting that JScript/DOM sucks for remote GUI applications. Kindly demonstrate exactly why this is - with code examples, so that the coders here can see what you mean. And with short, easy to understand words, so that people like me can see what you mean. But stop arguing from authority. It's time to lay it all out. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,707 by tablizer 10/16/01 11:20:57 PM Reply	and YOU don't have to present code examples? ________________ oop.ismad.com
Post #13,368 by admin 10/15/01 1:40:58 PM Reply	Patently false: DOM/JS is too complex A full-blown language has more potential for bugs because you have a more complex protocol to have to get right and keep upgrading, and more combinations that can do unpredictable things. Once again, my DOM/JS library runs unchanged on 4 different browsers. No updates necessary. No complexity at all (one line to include the library at the top of the HTML page). And it is delivered and running. And it took a few days to write. Where is the complexity? You're fighting a straw man. Regards, -scott anderson
Post #13,372 by pwhysall 10/15/01 1:45:42 PM Reply	"Come here! I'll bite you to death" Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,466 by static 10/15/01 10:30:40 PM Reply	No, it's not. It's called "partitioning the problem". Then you can use a modular approach with the right tool for the right section of the job. It's analogous to using CSS with HTML: HTML is used to markup the content's function and CSS is used to control how the marked up function is rendered. Wade. "All around me are nothing but fakes Come with me on the biggest fake of all!"
Post #13,307 by admin 10/15/01 10:03:02 AM Reply	Re: Turing-complete == more-problems-complete But it complicates the browser. A browser that only chomps "static" commands is going to be less complicated and have less problems and less security risks than one that chomps Turing-complete commands. Once again (with feeling): that complexity has already been spent. The DOM/JS browsers are already out there, already installed, already working, already available for our use. This is a non-argument. Not downloading code. I will agree that it may exchange an up-front wait for smaller, incrimental waits in some cases. But remember that SCGUI has asynchonous "send" options. Thus, the server can be checking stuff in-between "submits". Funny, I'm doing asynchronous sends with DOM/JS. No advantage to SCGUI there. Regards, -scott anderson
Post #13,350 by tablizer 10/15/01 1:07:33 PM Reply	The "assembler" argument again >> Once again (with feeling): that complexity has already been spent. The DOM/JS browsers are already out there, already installed, already working, already available for our use. This is a non-argument. << That is like saying, "well, since you can write a GUI handler in assembler, we will stick with assembler for everything." If you throw enough client-side coding at a complex, bloated HTML browser; yes, you can emulate more or less what SCGUI does. However, that misses the point that a REAL GUI protocol that works over HTTP is generally needed. Like I said, there is a general desire to do internet-enabled GUI's without a lot of pain. It can be FAKED with JS+DOM for only so long. ________________ oop.ismad.com
Post #13,359 by admin 10/15/01 1:27:21 PM Reply	And your proof is? Like I said, there is a general desire to do internet-enabled GUI's without a lot of pain. It can be FAKED with JS+DOM for only so long. And your list of things that can't be done with DOM/JS is where? Regards, -scott anderson
Post #13,371 by tablizer 10/15/01 1:45:15 PM Reply	first choice? really really? first? >> And your list of things that can't be done with DOM/JS is where? << And your list of things that can't be done in SCGUI? That is moot anyhow. I agree that with enough arm-twisting, JS+DUM can probably handle most or perhaps all of it. However, IT IS AWKWARD! For one, it requires at least 2 protocols. SCGUI is one protocol. 1 < 2 Second, JS+DUM is optimized for dancing brochure-like screen stuff, and NOT REMOTE BIZ GUI'S. If you were assigned the task of designing a remote biz GUI protocol that worked over HTTP, would JS+DUM be your FIRST choice?????????? That is the key question that you refuse to answer. Gotcha! ________________ oop.ismad.com
Post #13,378 by admin 10/15/01 1:56:17 PM Reply	Er, gotcha? And your list of things that can't be done in SCGUI? I don't need one. It doesn't run on my client's machines, therefore it is out of the running from square one. Besides, I'm not the one claiming we need the Extra Special Brand New ActiveVisualNET SCGUI plugin thingy to Solve All Our Programming Needs. Burden of proof is yours. However, IT IS AWKWARD! For one, it requires at least 2 protocols. SCGUI is one protocol. Once again, wrong. The developer using my JS/DOM library doesn't need to know any JS or DOM. Second, JS+DUM is optimized for dancing brochure-like screen stuff, and NOT REMOTE BIZ GUI'S. ONCE AGAIN, I am using it VERY SUCCESSFULLY in a "REMOTE BIZ GUI". As many times as you try to deny that, brush it under the rug, or otherwise ignore it, the fact remains that it WORKS. If you were assigned the task of designing a remote biz GUI protocol that worked over HTTP, would JS+DUM be your FIRST choice?????????? That is the key question that you refuse to answer. Gotcha! Er, sorry, I believe I already answered that (or at least implied it). Yes, it was my first choice, the implementation was extremely straightforward as compared to the complexity of the task, and in fact it will be going into production at the end of the year. Don't try to be clever, Bryce... you actually have to be clever for that to work. Regards, -scott anderson
Post #13,398 by tablizer 10/15/01 2:44:35 PM Reply	Lame first choice >> Burden of proof is yours. << Because you say it is? I canNOT inspect your JS-dom crap, I only have the words that come out of your mouth. >> Once again, wrong. The developer using my JS/DOM library doesn't need to know any JS or DOM. << The developer that made the library does. Plus, the browser still has to handle 2 protocols, regardless of how you divide your programming teams. The browser does not know nor care how the cubicles are arranged in your office. >> Er, sorry, I believe I already answered that (or at least implied it). Yes, it was my first choice << So if you were the KING OF PROTOCOLS, JS+DOM would be how you would design a remote GUI protocol? (I am talking macro here, not micro.) That sh*t is the best you can do? >> the implementation was extremely straightforward << Again, I have no way to independantly verify that task. Besides, there is more to GUI's than updating textboxes fast. ________________ oop.ismad.com
Post #13,405 by admin 10/15/01 3:24:56 PM Reply	Sez you. Because you say it is? I canNOT inspect your JS-dom crap, I only have the words that come out of your mouth. That doesn't mean you can't come up with a list of things that DOM/JS can't do/isn't suitable for doing. The developer that made the library does. Plus, the browser still has to handle 2 protocols, regardless of how you divide your programming teams. The browser does not know nor care how the cubicles are arranged in your office. Just as the developer who made the SCGUI browser needs to know VB or whatever you wrote it in. Who cares. So if you were the KING OF PROTOCOLS, JS+DOM would be how you would design a remote GUI protocol? (I am talking macro here, not micro.) No, if I were king of protocols, we'd have wxPython and Python embedded in Mozilla, but I'm not, and we don't. Again, I have no way to independantly verify that task. Besides, there is more to GUI's than updating textboxes fast. Yup, you're right, which is why you can do thing like add table rows and the like with the library as well. Regards, -scott anderson
Post #13,483 by tablizer 10/16/01 12:12:18 AM Reply	Grid? >> That doesn't mean you can't come up with a list of things that DOM/JS can't do/isn't suitable for doing. << [insert standard "assembler" argument] >> No, if I were king of protocols, we'd have wxPython and Python embedded in Mozilla, but I'm not, and we don't. << Then you would need a Turning Complete interpreter at the browser side. >> Yup, you're right, which is why you can do thing like add table rows and the like with the library as well. << Does it actually have a "grid" widget, or does it just use a bunch of textboxes aligned in a grid? ________________ oop.ismad.com
Post #13,553 by admin 10/16/01 9:21:28 AM Reply	Re: Grid? Then you would need a Turning Complete interpreter at the browser side. Yup. And I could care less. You haven't made the case that this is a bad thing. Does it actually have a "grid" widget, or does it just use a bunch of textboxes aligned in a grid? The latter, which is exactly how "grid widgets" are built in the first place. Again, since the developer doesn't know or care how it's done, this is a specious argument. Regards, -scott anderson
Post #13,708 by tablizer 10/16/01 11:28:54 PM Reply	more to grids than that >> The latter, which is exactly how "grid widgets" are built in the first place. << Real grid widgets also have vertical and horizontal scroll-bars and resizable column widths. >> Again, since the developer doesn't know or care how it's done, this is a specious argument. << Partitioning development so that one does not have to care about the other's work does not get away from relying on 2 protocols/langs. To recreate your solution, a company would have to hire somebody(s) who knows both JS and DOM. Your use of the term "generic library" is very loose. 1 < 2 ________________ oop.ismad.com
Post #13,732 by admin 10/17/01 9:29:10 AM Reply	Re: more to grids than that Real grid widgets also have vertical and horizontal scroll-bars and resizable column widths. One word: Frames. Partitioning development so that one does not have to care about the other's work does not get away from relying on 2 protocols/langs. To recreate your solution, a company would have to hire somebody(s) who knows both JS and DOM. Your use of the term "generic library" is very loose. So assume that I create such an open source library and release it. Do your objections then go away? Regards, -scott anderson
Post #13,820 by tablizer 10/17/01 4:17:32 PM Reply	Frame == Grid? Egad! >> [Real grid widgets also have vertical and horizontal scroll-bars and resizable column widths.] One word: Frames. << Frames are the kind of "half-ess GUI" solutions I keep talking about. It is tough to get the column name headers to line up as you scroll on both axi, for one. Plus, column widths still don't resize well without a lot of putzing around. I can't call that a "real" GUI. (In all fairness, my demo does not impliment an actual grid. But if it did, it would use a real GUI grid {a VB Grid widget in this case}, not a hokey simulation.) >> So assume that I create such an open source library and release it. Do your objections then go away? << They would be reduced. Plus, we all would have something to actually compare and inspect. ________________ oop.ismad.com
Post #13,850 by pwhysall 10/17/01 6:46:06 PM Reply	What's "Half-ess"? Half an S? Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,902 by tablizer 10/18/01 12:40:42 AM Reply	Reply re: S/2 >> What's "Half-ess"? Half an S? << It is a slightly nicer way to say "half-ass", you dumb-ass! Some people are offended by cussing due to religion or whatnot. I am just trying to respect their wishes a little bit. I am a nice person, you see. Got that fuckhead!? ________________ oop.ismad.com
Post #13,918 by pwhysall 10/18/01 2:55:33 AM Reply	Don't swear then If you don't want to swear, don't. Don't pretend to. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #14,102 by tablizer 10/19/01 12:42:47 AM Reply	anyhow, anybdy still wanna defend frames as grid substute? ________________ oop.ismad.com
Post #14,144 by admin 10/19/01 9:29:07 AM Reply	Not frames, frame. To satisfy the scrollbar requirement. Containing a single table. Regards, -scott anderson
Post #14,265 by tablizer 10/20/01 2:47:09 AM Reply	problems with that approach 1. The column headings don't stay at top or don't stay aligned if there is horizontal scrolling. (Most grids can "lock" columns vertically also.) 2. Frames mess up or confuse bookmarks (favorites) and printing. 3. You can't resize the column widths (by dragging the column heading borders). ________________ oop.ismad.com
Post #17,435 by tablizer 11/8/01 11:23:21 PM Reply	Nobody is defending "frames == grid" after all these weeks Dare I use the word............"victory"? (I normally don't brag about such, but after all the unjustified clubby hammering I get from you guys, I feel entitled.) ________________ oop.ismad.com
Post #17,456 by pwhysall 11/9/01 5:41:15 AM 11/9/01 5:42:46 AM Reply	Bryce No-one's talking about it because no-one gives a shit what you do or think. We've explained time and time again about this, and if you don't want to accept the clue I don't really think there's any profit to be gained in pursuing the matter. Code your stuff the way you want to -- but don't be surprised when you can't get a programming job with "oop.ismad.com" in your signature. The only thing worse than the OO zealots in comp.object is your continual[1] clue-free yammering about stuff that the people you're yammering at don't care about. You only add noise to those discussions. (Yes, I lurk on comp.object - it's a fascinating, growing psychological document) [1] And it bloody is continual, too - I counted 80 posts in a day from you, once. That's not "having a debate", that's "having a an obsessive-compulsive disorder". Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal] Edited by pwhysall Nov. 9, 2001, 05:42:46 AM EST Expand All History
Post #17,533 by tablizer 11/9/01 2:45:53 PM Reply	I will bet you $100.00 >> We've explained time and time again about this, and if you don't want to accept the clue I don't really think there's any profit to be gained in pursuing the matter. << "accept a clue" is a personal insult. If you wish to insult somebody over technical claims, then please be prepared to back it up. If you want to discontinue your participation in this discussion, then simply say, "I disagree with you, but do not wish to participate in this discussion anymore". There is no need to post hit-and-run insults, like your "clue" shit. Such insults just make me more determined to present more details to back my view. Insults DON'T make me go away. If you can get HTML to do a grid "right" WRT to the column heading scrolling and left-locked columns, I will give you $100.00. ________________ oop.ismad.com
Post #17,590 by pwhysall 11/9/01 5:29:28 PM Reply	I don't care Bet all you like. I still don't care. You don't listen amd I don't give a flying fuck. You want an argument? Go troll elsewhere. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #17,809 by tablizer 11/11/01 9:57:59 PM Reply	And stop it with the "listen" sh8t You ain't no teacher, you are a preacher. Show me science and metrics and western reductionalism, not cliches and scripture. ________________ oop.ismad.com
Post #13,394 by ChrisR 10/15/01 2:38:11 PM Reply	Asynchronous xmit Funny, I'm doing asynchronous sends with DOM/JS. No advantage to SCGUI there. I haven't been following this right shifted thread too closely, but I am interested in hearing how you achieved the asynchronous transmission (assuming you are at liberty to discuss it). No need to get real specific, just wondering about the general approach. I've got a management tool that I wrote a couple of months back - in some ways it's similar to a project management tool. It draws a dynamic tree where nodes can be added based on the rights of the users. Currently, each node addition/subtraction is requiring a complete turnaround - though I do some cheats here and there for a couple of screens. Anyhow, it sounds like your approach might be useful for some aspects of my application. :-)
Post #13,397 by admin 10/15/01 2:43:32 PM Reply	Re: Asynchronous xmit Open an "endless" HTTP session in a hidden frame (or in another "pop-up" style window) and use that for communication back from the server. If you need to communicate to the server, do another POST. The server connection sends back Javascript commands to the hidden frame that are executed as they arrive. There are some intricacies (batching commands for efficiency and the like) but those are the basics. It's actually pretty simple. If that isn't sufficient, you can use a Java applet for two-way communication instead. It doesn't seem necessary, however. Regards, -scott anderson
Post #13,414 by ChrisR 10/15/01 4:25:27 PM Reply	Thanks... I thought that's what you & TSEliot were discussing - I just couldn't tell whether that's the route you took. In my case, I don't really want to use applets because of various issues (firewalls, JVM versioning, etc). I have been doing some popup browsers that synchronize and redraw the display based on operator input for the popup browser - but only to a limited extent for a few of the easier screens. Sooner or later, I need to account for having multiple users hitting the same info and updating all the attached clients as the database information is modified.
Post #13,416 by admin 10/15/01 4:47:18 PM Reply	We're using it for updates... Thousands of clients at a time. We have an in-house messaging server that is connected to by the endless servlet pushing the JS. Regards, -scott anderson

Welcome to IWETHEY!