VB, Delphi, Powerbuilder, etc.

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

Welcome to IWETHEY!