Top Mud Sites Forum - View Single Post

shadowfyr · 06-23-2008, 11:30 AM

Didn't say having good specs is "automatic".

As for getting it out to the client... A lot of people end up pushing out things like Java clients. The problems being that a) if you use "real" java, or something similar, then the install of the engine is going to be bigger than any client download (unless they already have it for some reason, and b) you are relying on *their* libraries and engine to be stable, which they may not be. This especially becomes true when using anything in the Active Script line, like Jscript. You are fine, as long as the client doesn't introduce on-demand code. The moment you start adding and removing a large number of blocks of code, like, for example, in triggers, where you want to "temporarilly" run some bit of code that changes each time the trigger text varies, then garbage collection blows up on you, and you get a slow and persistent memory leak. As near as those of us that used to use them with Mushclient can tell, this is a **universal** problem with how Active Script based engines handle such on-demand code execution.

Frankly, I am surprised that surfing too many web pages doesn't crash IE from the same bug, though, they may be doing something different, undocumented, or just "left out" of the instructions that everyone else uses to integrate the bloody scripts.

In any case, I don't personally "trust" things that run on those languages. The underlying engines often have bugs in them, or odd implementation problems. And even the full Java seems to have those issues. Its taken multiple versions of some bittorrent clients to get them "stable", and not all of the issues with that where in the code of the client. Many where problems in how certain things, like memory, where being handled "in" the engines.

At least with a compiled application, you can be fairly certain that the behavior will remain stable, in terms of how it worked when released, for as long as the OS it runs on still exists, or at least "supports" what ever libraries you ran it with. This isn't "quite" as certain with all the fancy, "You don't need to install nothing, just let the intertubes feed you the applet.", style stuff.

06-23-2008, 11:30 AM	#43
shadowfyr Senior Member Join Date: Oct 2002 Posts: 310	Re: custom clients. Good or bad? Didn't say having good specs is "automatic". As for getting it out to the client... A lot of people end up pushing out things like Java clients. The problems being that a) if you use "real" java, or something similar, then the install of the engine is going to be bigger than any client download (unless they already have it for some reason, and b) you are relying on their libraries and engine to be stable, which they may not be. This especially becomes true when using anything in the Active Script line, like Jscript. You are fine, as long as the client doesn't introduce on-demand code. The moment you start adding and removing a large number of blocks of code, like, for example, in triggers, where you want to "temporarilly" run some bit of code that changes each time the trigger text varies, then garbage collection blows up on you, and you get a slow and persistent memory leak. As near as those of us that used to use them with Mushclient can tell, this is a universal problem with how Active Script based engines handle such on-demand code execution. Frankly, I am surprised that surfing too many web pages doesn't crash IE from the same bug, though, they may be doing something different, undocumented, or just "left out" of the instructions that everyone else uses to integrate the bloody scripts. In any case, I don't personally "trust" things that run on those languages. The underlying engines often have bugs in them, or odd implementation problems. And even the full Java seems to have those issues. Its taken multiple versions of some bittorrent clients to get them "stable", and not all of the issues with that where in the code of the client. Many where problems in how certain things, like memory, where being handled "in" the engines. At least with a compiled application, you can be fairly certain that the behavior will remain stable, in terms of how it worked when released, for as long as the OS it runs on still exists, or at least "supports" what ever libraries you ran it with. This isn't "quite" as certain with all the fancy, "You don't need to install nothing, just let the intertubes feed you the applet.", style stuff.