Re: Turing-complete == more-problems-complete

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!