Ahhhh. Circumventing another man's app by DESIGN.

Post #9,487 by tseliot 9/17/01 3:11:12 PM Reply	Ahhhh. Circumventing another man's app by DESIGN. Gotcha :D If you control the deployment: I'd look up how corp's (like big ISP's) override that graphic and make it a non-animated one. Maybe. If not: I seriously doubt it's something under the direct control of JS. Usually (as I'm sure you know) you'd separate the interface from the app a bit more, and just use the app for the control (since it's hardly real-time anyway). IOW, let the client side control the pull on an as-needed basis. What's on the back-end? Persistent servlet maybe? This is territory where real Java applets stop looking quite as ugly as they usually do... That's her, officer! That's the woman that programmed me for evil!
Post #9,489 by admin 9/17/01 3:17:30 PM Reply	Don't control the deployment that much. And we definitely don't want to stop the spinner from working for every page, just the one. The app is very realtime... we hit about 40 updates per second with our current data feed. Right now I'm batching at one batch per second to control efficiency. I've had it up to 200 updates/sec with no noticeable lag and CPU usage at about 20% in the browser (PIII 800). The Java applets in this case are actually less efficient than the Javascript feed by a good bit. The app has a never ending servlet that sends Javascript update calls to the invisible frame. The browser executes the calls as it receives them. Very clean, although there are some downsides (the spinner never stopping being one of them). I could drop the browser into kiosk mode, but we'd rather not change the interface that much if possible. It might be best to sell it as a feature -- "the spinner tells you that you're still receiving updates". The main concern is that people are going to be hitting the Stop button when they see the spinner continuing to roll. Regards, -scott anderson
Post #9,505 by tseliot 9/17/01 4:17:29 PM Reply	Well, sure. The Java applets in this case are actually less efficient than the Javascript feed by a good bit. We're pretty much talking about the difference between one connection per update and one per session. But I don't see how you can work around that slow mem buildup otherwise...I'd say that's a bigger problem than the throbbing icon.. ;) Lessee...one batch per second? How about restarting the document every 30 seconds or so? Maybe have the feed on one (invisible) frame and the display on another, and just restart the feed frame regularly. Wouldn't solve the throbber problem, but might help client memory. That's her, officer! That's the woman that programmed me for evil!
Post #9,506 by admin 9/17/01 4:27:10 PM Reply	One connection per session regardless. With both the applet and the javascript. Both end up making a perpetual socket to the back end. The applet, however, uses more CPU during updates. Mainly (we think) because it starts up a new javascript interpreter for each call. The memory buildup can be solved exactly as you describe, but we'll probably refresh the page every 15 or 30 minutes, not every 30 seconds. The current discussion, however, is whether or not the throbber will sow confusion amongst the ranks of the users. :-P Regards, -scott anderson
Post #9,640 by pwhysall 9/18/01 6:21:14 PM Reply	Feh. You should be using SCGUI, you know. -- Peter Shill For Hire
Post #9,658 by admin 9/18/01 11:02:17 PM Reply	ROFL Strangely enough, Peter, the functionality of the Javascript/DOM stuff I wrote bears an odd resemblance to the requirements SCGUI is supposed to fulfill... ;-) But of course I can't be right, since that isn't possible. We need a NEW protocol. Regards, -scott anderson
Post #11,505 by tablizer 10/3/01 2:28:23 PM Reply	Auto refresh? Couldn't you make the browser refresh itself every X seconds using the Meta tag or something? (I don't remember the exact syntax, but can look it up if you want). Or, are you try to put the updates only into specific "spots" on the screen without doing an entire redraw? (BTW, I saw the SCGUI dig. BTW2, there is a browser thingy called "Charlotte" that is somewhat similar to SCGUI.) ________________ oop.ismad.com
Post #11,512 by pwhysall 10/3/01 2:33:41 PM Reply	Re: Auto refresh? <META REFRESH>, if I remember correctly. An abomination, on a par with the <BLINK> tag. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #11,589 by kmself 10/3/01 6:34:33 PM Reply	...which should be subject to user override Several websites I'm aware of use this. As my web access is subject to interruption, I'm made aware of this when the page isn't there (refresh results in no access). Thankyouverymuch, I can refresh my own browser. Shame: The New York Times (but not the Archives pages), FuckedCompany (but what do you expect?). `-- Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com] What part of "gestalt" don't you understand?`
Post #12,004 by tablizer 10/5/01 7:10:35 PM Reply	We are talking B-to-B or intranet, right? It would not be that hard to have a user option to control the refresh rate for a given page. Although I am thinking about having the rate setting be stored server-side (and used to generate the meta tag), client-side might also be possible. I have also kicked around the idea of adjusting the refresh rate based on traffic density in some apps. ________________ oop.ismad.com
Post #11,557 by admin 10/3/01 4:39:53 PM Reply	The application uses auto refresh now. And as you posited, we want to be able to update specific portions of the page without recreating the entire page. Regards, -scott anderson
Post #12,006 by tablizer 10/5/01 7:18:25 PM Reply	Why is auto-refresh not satisfactory? >> The application uses auto refresh now.... And as you posited, we want to be able to update specific portions of the page without recreating the entire page. << True, auto-refresh is not the most efficient for spot updates, but then again, it aint SCGUI. (I know you claim DOM comes close, but DOM is not a real GUI. What we need is a real web-friendly GUI protocol, and DOM ain't it.) If beauty is not a primary requirement, then you may be able to simplify the contents to reduce it's size. However, esthetics are all that many PHB's judge by. ________________ oop.ismad.com
Post #12,170 by admin 10/7/01 10:45:43 PM Reply	Because I work on actual large scale applications. 3000-5000 users at once, with updates coming at around 6-12 per second, on very data-intensive pages. Do the math. Auto-refresh ain't gonna work. I didn't say that DOM comes close. I said that there isn't anything you want to do with SCGUI that isn't achievable with DOM, and in fact in this instance I have done it with DOM. It runs in both IE 5.x and Netscape 6/Mozilla with no browser-specific coding whatsoever. What we need is a real web-friendly GUI protocol, and DOM ain't it. Patently false. Once again, your lack of experience and need to reinvent the wheel in your own flawed image is clouding your judgement. Regards, -scott anderson
Post #12,299 by tablizer 10/8/01 4:28:07 PM Reply	depends on needed refresh rate >> Do the math. Auto-refresh ain't gonna work. << How often do you need to refresh? That is a key portion of any equation. Also, you could perhaps divide the task up onto different servers and IP addresses. Database access/replication may then be the bottleneck. Or perhaps update the webpage image to the mirror servers every half-second or so if they are not customized-per-user pages. Or, perhaps make the refresh rate part of a marketing compaign. For example, the base service may refresh every minute, but higher-end customers can get higher rates. Hook 'em with basic services, and then fee them to death to get faster rates. Think like a PHB instead of an engineer. It is not a problem, but a way to collect fees :-) Besides, not all customers may need instant rates. If only 10 percent really need fast refresh, then why spend all the money to give EVERYBODY fast updates? >> Once again, your lack of experience and need to reinvent the wheel in your own flawed image is clouding your judgement. << I have a runnable demo with source code. You have not presented any source code, only braggings in text format. (Sorry about the paragraph formatting. I can't seem to kick the line-break habit. I picked it up in my VAX days, and it keeps coming back to haunt me if I use it for a short while again. An old "war" reflex.) ________________ oop.ismad.com
Post #12,300 by admin 10/8/01 4:39:16 PM Reply	Re: depends on needed refresh rate How often do you need to refresh? That is a key portion of any equation. I already pointed that out. This is a realtime application. Thousands of clients receiving 6-12 updates per second. Also, you could perhaps divide the task up onto different servers and IP addresses. Database access/replication may then be the bottleneck. It is the bottleneck already. Or perhaps update the webpage image to the mirror servers every half-second or so if they are not customized-per-user pages. They are customized. Besides, not all customers may need instant rates. If only 10 percent really need fast refresh, then why spend all the money to give EVERYBODY fast updates? Because we will have thousands of clients getting 6 to 12 updates per second. The requirements are already set. Stop trying to change the requirements to fit your paradigm. >> Once again, your lack of experience and need to reinvent the wheel in your own flawed image is clouding your judgement. << I have a runnable demo with source code. You have not presented any source code, only braggings in text format. I'm sure if you'd like to pay several thousand dollars or sign an NDA, my company would be glad to show you the source code. Frankly, I don't give a rat's ass if you believe me or not. Anyone with half a brain and a Javascript/DOM reference could do the same. Regards, -scott anderson
Post #12,437 by tablizer 10/9/01 12:36:45 PM Reply	Nothing is truely "instant" >> I already pointed that out. This is a realtime application. << Nothing is truly "instant". One definition of "realtime" is that it is guarenteed to happen within X amount of time. If this is the definition you are using, then there must be an X. >> Because we will have thousands of clients getting 6 to 12 updates per second. The requirements are already set. Stop trying to change the requirements to fit your paradigm. << From a management perspect, "instant" is NOT free. Perhaps if management saw the costs of different turnaround times, they may rethink their marketing. A good business does not spend billions on features that people don't really need. You might even get MORE business because you can offer the slower-updated service for much less money. The one-speed-fits-all may drag down the lower end of the sales spectrum and bloat your equipment and networking budget way beyond what it needs to be. It would be like Toyota putting Lexus engines in ALL models. Perhaps your company only focuses on Lexus-end clients. That is fine. Just say so. I don't work there and can't read minds. Now, perhaps you have no influence over such decisions or don't care, but it seems like a legit issue to me. I like discussing such issues. If you don't, just say so instead of getting pissy. >> Anyone with half a brain and a Javascript/DOM reference could do the same. << With enuf effort it could be done in assembler. However, that does not make it convenient. HTML and DOM is not GUI. Sure, you can emulate it with enuf goofing around. Businesses want remote GUI's that are network-friendly. HTML is great for brochure-like content, but NOT data-intensive interactive biz apps. Besides, SCGUI does NOT need client-side content scripting. ________________ oop.ismad.com
Post #12,454 by admin 10/9/01 2:14:14 PM Reply	Re: Nothing is truely "instant" >> I already pointed that out. This is a realtime application. << Nothing is truly "instant". One definition of "realtime" is that it is guarenteed to happen within X amount of time. If this is the definition you are using, then there must be an X. I gave that to you. 6 to 12 updates per second. From a management perspect, "instant" is NOT free. Perhaps if management saw the costs of different turnaround times, they may rethink their marketing. A good business does not spend billions on features that people don't really need. You might even get MORE business because you can offer the slower-updated service for much less money. The one-speed-fits-all may drag down the lower end of the sales spectrum and bloat your equipment and networking budget way beyond what it needs to be. From a management perspective, we need to provide 6 to 12 updates per second to thousands of clients. The management here consists of software architects, and the decision was made in full comprehension (unlike yours) of the requirements. It would be like Toyota putting Lexus engines in ALL models. Perhaps your company only focuses on Lexus-end clients. That is fine. Just say so. I don't work there and can't read minds. No, and you can't read text either, when it says "6 to 12 updates per second to thousands of clients". Now, perhaps you have no influence over such decisions or don't care, but it seems like a legit issue to me. I like discussing such issues. If you don't, just say so instead of getting pissy. It isn't a legit issue. I told you the requirements. With enuf effort it could be done in assembler. However, that does not make it convenient. HTML and DOM is not GUI. Sure, you can emulate it with enuf goofing around. Businesses want remote GUI's that are network-friendly. HTML is great for brochure-like content, but NOT data-intensive interactive biz apps. Besides, SCGUI does NOT need client-side content scripting. I wrote the Javascript/DOM implementation in two days, with documentation, comments, and unit tests. How long did it take you to write SCGUI? My implementation runs on all of the browsers currently being used at our clients. How many people out there have an SCGUI-compliant browser installed on their desktops? Speaking of data-intensive interactive biz apps, what the hell do you think an online bond trading application is? And finally, my solution doesn't require client-side scripting either. Just the inclusion of the library (one line) and proper attention paid to attributes on realtime-enabled HTML tags. Simplicity itself, from the viewpoint of the developer using the library. ________________ oop.ismad.com Regards, -scott anderson
Post #12,699 by tablizer 10/10/01 3:39:19 PM Reply	JavaScript but not client-side script? >> From a management perspective, we need to provide 6 to 12 updates per second to thousands of clients. << It just sounds like an odd requirement. I can imagine a data feed to other systems directly that needs that kind of turnaround time, but not interactive except a select few clients. Since I can't walk around that biz and ask questions, I am forced to take your word for it. Note that a competitor could perhaps offer a similar service for 1/4 the cost by not having movie-speed updates, and kick your popo's. >> I wrote the Javascript/DOM implementation in two days, with documentation, comments, and unit tests. How long did it take you to write SCGUI? << If everybody thot that way, we would still be using COBOL and Fortran because nobody would bother to make new compilers. >> And finally, my solution doesn't require client-side scripting either. << I thot you said it used JavaScript. Does the JavaScript run on the server? ________________ oop.ismad.com
Post #12,701 by admin 10/10/01 3:46:31 PM Reply	Re: JavaScript but not client-side script? It just sounds like an odd requirement. I can imagine a data feed to other systems directly that needs that kind of turnaround time, but not interactive except a select few clients. Since I can't walk around that biz and ask questions, I am forced to take your word for it. Traders watch their screens like hawks. They need the updates as soon as they happen. Note that a competitor could perhaps offer a similar service for 1/4 the cost by not having movie-speed updates, and kick your popo's. And if the realtime service is part of the basic offering? No difference then. >> I wrote the Javascript/DOM implementation in two days, with documentation, comments, and unit tests. How long did it take you to write SCGUI? << If everybody thot that way, we would still be using COBOL and Fortran because nobody would bother to make new compilers. And if everyone just ran off to write their own implementation every time because they couldn't be bothered to use existing, perfectly usable tools, we'd never get anything done at all. I thot you said it used JavaScript. Does the JavaScript run on the server? No, in the browser. As a library include, no different (in principle) than any plugin or other similar method. The page developer doesn't have to know jack squat about Javascript or client-side scripting to use the functionality. Regards, -scott anderson
Post #12,800 by tablizer 10/10/01 10:42:52 PM Reply	that is still client-side script/applet >> And if the realtime service is part of the basic offering? No difference then. << You are ignoring price. Anybody want to form a company to undercut Scott's company by offering a similar services, but say with 2-second updates for 1/4 the cost? (A premium service may be faster. Or, we could leave that niche to Scott.) >> And if everyone just ran off to write their own implementation every time because they couldn't be bothered to use existing, perfectly usable tools, we'd never get anything done at all. << HTML + DOM is NOT gui. You can fake it only so far. >> No, in the browser. As a library include, no different (in principle) than any plugin or other similar method. The page developer doesn't have to know jack squat about Javascript or client-side scripting to use the functionality. << It does not matter, that is STILL client-side scripting/applets. Being compresses or encrypted or whatever is only a side issue. SCGUI does not need any app-specific client code. ________________ oop.ismad.com
Post #12,843 by Yendor 10/11/01 1:48:36 AM Reply	Fundamental disconnect You are ignoring price. Anybody want to form a company to undercut Scott's company by offering a similar services, but say with 2-second updates for 1/4 the cost? (A premium service may be faster. Or, we could leave that niche to Scott.) And you are ignoring the fact that you don't know the bond/stock market and traders all that well. I've heard Scott talk about the stuff he's doing. Real-time is a basic need for anything relating to financial markets. A 2-second lag can mean the difference between making hundreds of thousands of dollars, and losing millions sometimes. And if you don't want to take Scott's word for it, then take my wife's. She's been working for a large, international media company for better than 4 years now in their division that works with the stock market. The application that she writes for requires real-time updates because it's used by real, live traders in the pits at all of the world's stock exchanges. From the Hang Seng to the Merc, from the NYSE to the Nikkei, her application is used. Why? Because it provides access to the data faster than any of the competitors. People pay thousands of dollars per month to have access to her app and its data coming live from the stock markets around the world. Simply because it provides real-time updates as they happen, thousands of times per second, across thousands of stocks. I also interviewed with this company a few years ago. At the time, they mentioned how much time their app is contracted to have for outages. If I remember correctly, that number was on the order of 3-12 hours. Per year. Total. Around the world. And, so far as I know, they've kept well under that. To put it simply, traders cannot get updated data soon enough. They are willing to pay exorbitant amounts of money to shave off fractions of a second from the response time on their data feeds. -YendorMike "The problems of the world cannot possibly be solved by the skeptics or the cynics whose horizons are limited by the obvious realities. We need people who dream of things that never were." - John F. Kennedy
Post #12,867 by admin 10/11/01 10:02:35 AM Reply	Re: that is still client-side script/applet You are ignoring price. Anybody want to form a company to undercut Scott's company by offering a similar services, but say with 2-second updates for 1/4 the cost? (A premium service may be faster. Or, we could leave that niche to Scott.) I think Mike answered this one well enough. >> And if everyone just ran off to write their own implementation every time because they couldn't be bothered to use existing, perfectly usable tools, we'd never get anything done at all. << HTML + DOM is NOT gui. You can fake it only so far. Seems to work here. I guess an online bond trading application isn't a real business application, though, huh? It does not matter, that is STILL client-side scripting/applets. Being compresses or encrypted or whatever is only a side issue. SCGUI does not need any app-specific* client code.* 1) Why does it matter? Yeah, let's all run out and install a completely new browser on our machines to get the SAME functionality that can be had by including a client-side library on the existing browsers. 2) I'm interested in how you intend to prove the proposition that including a generic library is equivalent to app-specific client code. If I wanted to, the Javascript library I have could just as easily use SCGUI commands. Where's the difference? Regards, -scott anderson
Post #12,923 by tablizer 10/11/01 1:54:05 PM 10/11/01 2:06:01 PM Reply	"generic" by what scope? >> I think Mike answered this one well enough. << Alright, I give up on that point. You need movie speed. (I always thot that to avoid last-minute surprises, bid records have optional "limits" (tolerance), so that the transaction is cancelled if the price suddenly jumps or pluments just after you push the button.) >> I guess an online bond trading application isn't a real business application, though, huh? << Like I said in another thread, you are confusing old OO and SCGUI arguments here. >> I'm interested in how you intend to prove the proposition that including a generic library is equivalent to app-specific client code. << "Generic" for what? What is your criteria for "generic" here? If it is generic, then why do they have to download it? >> Yeah, let's all run out and install a completely new browser on our machines to get the SAME functionality that can be had by including a client-side library on the existing browsers. << A SCGUI browser would be like getting an HTML browser. I agree it would be a pain until it was wide-spread. I still think that the biz world needs a generic GUI protocol that can run on top of HTTP without the burden of executable content. I keep bumping into such a need time after time at different companies I have worked or contracted for. Yes, you can semi-emulate or get around it with tricks and nicks, but everything keeps pointing toward the need for a SCGUI-like browser. If you disagree with my assessment, so be it. I realize in your particular situation, making a SCGUI-like browser right now is probably not feasible. I am just pointing out an industry-wide need for a GUI browser standard that works well over HTTP. ________________ oop.ismad.com Edited by tablizer Oct. 11, 2001, 02:06:01 PM EDT Expand All History
Post #12,969 by admin 10/11/01 3:57:51 PM Reply	Re: "generic" by what scope? Alright, I give up on that point. You need movie speed. (I always thot that to avoid last-minute surprises, bid records have optional "limits", so that the transaction is cancelled if the price suddenly jumps or pluments just after you push the button.) Bid limits have nothing to do with timing. They have to do with saying "I will accept your bid, as long as it is within this limit." Like I said in another thread, you are confusing old OO and SCGUI arguments here. Like I said in that other thread, YOU were the one who brought it up. "Generic" for what? What is your criteria for "generic" here? If it is generic, then why do they have to download it? Explain to me how downloading a generic library is "app-specific" please. A SCGUI browser would be like getting an HTML browser. I agree it would be a pain until it was wide-spread. I still think that the biz world needs a generic GUI protocol that can run on top of HTTP without the burden of executable content. I keep bumping into such a need time after time at different companies I have worked or contracted for. Yes, you can semi-emulate or get around it with tricks and nicks, but everything keeps pointing toward the need for a SCGUI-like browser. If you disagree with my assessment, so be it. Except 1) the HTML browser comes with the OS now, and the SCGUI browser never will, 2) what "burden of executable content"?? WTF does the app developer care how the page is done, if they don't have to do any Javascript coding themselves? This is a spurious requirement you've made up for the sake of disallowing any solution that doesn't fit your preconceptions of How It Must Work. Regards, -scott anderson
Post #13,204 by tablizer 10/12/01 9:27:32 PM 10/12/01 9:28:23 PM Reply	security risks >> Bid limits have nothing to do with timing. << I did not say they did. "Suddenly" was not meant to imply that they were time-related, but what the user was worried about. >> Explain to me how downloading a generic library is "app-specific" please. << It may be the only application that a user uses with a given library. It may be generic to the programmer, but not necessarily from the browser's perspective. >> what "burden of executable content"?? WTF does the app developer care how the page is done, if they don't have to do any Javascript coding themselves? << Downloaded exec/scripts: 1. Complicate the browser design 2. Increase versioning problems 3. Create security risks 4. Increase download times 5. More things to crash ________________ oop.ismad.com Edited by tablizer Oct. 12, 2001, 09:28:23 PM EDT Expand All History
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
Post #13,306 by admin 10/15/01 9:59:21 AM Reply	Re: security risks It may be the only application that a user uses with a given library. It may be generic to the programmer, but not necessarily from the browser's perspective. Uh, buh? That can be the case with any library. You can say the same thing about SCGUI if you're only running a single app with it. WTF kind of a stupid argument is that?? A generic library is a generic library. It gets downloaded once and cached. You're reaching. 1. Complicate the browser design Are already coded, complete, and installed on 90+% of the desktops out there. The complexity has already been paid. Insufficient argument. 2. Increase versioning problems In what way? As opposed to SCGUI where the user has to download a completely new version of the browser when new functionality comes out or is needed, in stark contrast to downloadable JS libraries which change immediately on the server with the app that includes them? SCGUI has the versioning problems here. 3. Create security risks On a secure VPN application used via an extranet or intranet connection? In what way? 4. Increase download times Wrong. The JS is downloaded once in a library and cached. 5. More things to crash What? How so? How are there "more things to crash" than any other client-server architecture? You're reaching again. Regards, -scott anderson
Post #13,344 by tablizer 10/15/01 12:59:26 PM Reply	Skinny client, skinny needs >> Uh, buh? That can be the case with any library. You can say the same thing about SCGUI if you're only running a single app with it. << In SCGUI you don't download libraries because most of the processing is on the server, not the client. >> [Complicate the browser design] Are already coded, complete, and installed on 90+% of the desktops out there. << What do you mean by 90+%? 90+% of all desktops with browsers? So you have to emulate on the other 10 percent? >> In what way? As opposed to SCGUI where the user has to download a completely new version of the browser when new functionality comes out or is needed, in stark contrast to downloadable JS libraries which change immediately on the server with the app that includes them? SCGUI has the versioning problems here. << When it has vector support, it can draw any fricken shape or gizmo you want. However, it is designed to move most of the processing to the server. Skinny client, skinny needs. >> [Create security risks] On a secure VPN application used via an extranet or intranet connection? In what way? << In your particular case, it may not matter. However, much B-to-B is not via VPN. >> [Increase download times] Wrong. The JS is downloaded once in a library and cached. << Everytime the cache runs out, a download wait. I have seen applet downloads that take around 5 minutes on a T1 line. And, the bigger it is, the more it will need changing in many cases. >> [More things to crash] What? How so? How are there "more things to crash" than any other client-server architecture? You're reaching again. << Who said anything about client-server? ________________ oop.ismad.com
Post #13,351 by pwhysall 10/15/01 1:09:15 PM Reply	Re: Skinny client, skinny needs >> [Complicate the browser design] Are already coded, complete, and installed on 90+% of the desktops out there. << What do you mean by 90+%? 90+% of all desktops with browsers? So you have to emulate on the other 10 percent? Yes, 90% of all desktops run either Internet Explorer or Mozilla, or some other DOM/Javascript capable browser. The number of SCGUI platforms is...ummm...two. You and your buddy. That's it. Peter Shill For Hire [link\|http://www.kuro5hin.org\|There is no K5 Cabal]
Post #13,391 by tablizer 10/15/01 2:33:40 PM Reply	The "assembler" argument again After all this time I thot you guys would be able to predict my responses and save me some typing. However, you just keep proving that you don't really understand my point of view. ________________ oop.ismad.com
Post #13,395 by admin 10/15/01 2:40:19 PM Reply	Your "point of view" Is that you've come up with something new. What we are (unsuccessfully) trying to get across to you is that you are simply advocating the use of 5250/3270 to replace what 5250/3270 (at some level) evolved into. Regards, -scott anderson
Post #13,399 by tablizer 10/15/01 2:46:54 PM Reply	I dn't care whthr it's new nor not. It is better than JS+DOM ________________ oop.ismad.com
Post #13,401 by admin 10/15/01 2:56:39 PM Reply	You have yet to demonstrate that. Regards, -scott anderson
Post #14,578 by addison 10/22/01 1:06:47 PM Reply	Re: Your "point of view" What we are (unsuccessfully) trying to get across to you is that you are simply advocating the use of 5250/3270 to replace what 5250/3270 (at some level) evolved into. And ignoring the other solutions that came up to deal with the shortcomings of 3270.. (X, ISA).. (I note that Exceed now has some sort of X-plug in for Win32, so you could (if I read this right) just shove X to people with the plugin... ) I thought that sounded somewhat nifty. I still think Bryce needs to spend a couple weeks playing with X and finding out how nice it is for what he wants to do. Addison
Post #14,658 by CRConrad 10/22/01 6:47:47 PM Reply	"Plug-in"? Uhm, isn't that called an X Server...?
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
Post #60,255 by pwhysall 10/30/02 2:14:03 PM Reply	I'll have a large anchovy pizza, please. Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]

Welcome to IWETHEY!