[MUD-Dev] Java and Javascript

[Matt Chatterley]

On Mon, 16 Feb 1998, Caliban Tiresias Darklock wrote:
> At 03:37 PM 2/16/98 +0000, Matt Chatterley wrote:
> >On Mon, 16 Feb 1998, Caliban Tiresias Darklock wrote:
> >> At 11:11 AM 2/14/98 +0000, Mat Chatterley wrote:
> >> >
> >> >Absolutely agreed that the browser interface is not useful. If anything,
> >> >it means a waste of resources!
> >
> >Albeit in a slightly ranty form, this contains some very interesting
> >points (and I'm not certain to what degree this is serious, but in either 
> >case, an interesting attitude - not necessarily Caliban's). Dissection in
> >parts follows.
> 
> Well, I went flying off on a tirade as usual. I have a tendency to do that,
> and I just hope I'm not leaving people with the idea that I'm some bitter,
> pathetic jerk who has nothing better to do than argue with people. ;)

Don't worry, we know you love us really. ;)
  
> >> No it doesn't! Quit assuming that your MUD is the only damn thing I want to
> >> do while I'm online! I want all the same integrated features I'm used to,
> >
> >But given that assumption (a reasonable one when writing a mud client, I
> >think), 
> 
> I don't. I have not done one and only one thing on my computer for years. I
> average eight to twelve open applications at a time (right now I have 16
> open).

Sounds like me and Xterms. One for the compiler, one for tf, one for pine,
an editor (xjed), one running rc5des, and a few spares that I forgot I'd
opened. Only three running right now (a small miracle).
 
> >using the browser environment when not necessary *would* entail a
> >waste of resources. This is perhaps not a valid enough argument on its own
> >(OTOH, Netscape puts my machine through the wringer, and I have 64 mbs of
> >ram plus a fast disk). Even so, its a design thing - I hate to see big and
> >unwieldy things being used for tasks that can be accomplished with
> >smaller, neater programs (and also, it makes things more accessible to
> >'lower power' machines). Of course, it means I don't have to deal with
> >bugs in other peoples software, too.
> 
> I can see both sides of this issue. I have a healthy aversion to canned
> code and downloaded components, but sometimes you have to ask yourself why
> you ought to build something someone else already did. The major question
> is whether the benefit outweighs the liability -- for example, if you build
> your client in Java, you inherit any security bug that might be found in
> Java. You have to ask yourself whether that's a risk worth taking; do you
> want the software done and out the door faster, or do you want it
> bulletproof? Time is a commodity, but so is reliability... and when you use
> someone else's framework, you're investing a lot of trust in that person. 

Certainly I *do* conceed that two people are fairly unlikely to agree
completely here; since it IS a very interprative issue (is that a word? I
mean; it all comes down to your personal views and outlooks). My client is
actually building up to being 'canned' by the way; it exists as a series
of Java classes (I think some will soon be Java.beans, once I get another
text on them), and will *very* shortly have the ability to automatically
download and update itself (asking for permission first). It'll also
communicate with a servlet to maintain a mudlist (this is further off, but
a similar feature).

Re: security bugs in Java, this is somewhat irrelevant, since you cannot
really code at a more 'basic' level than the language you are using. My
work would be out a bit faster if it were browser-based, but it wouldn't
really do what *I* want it to do (and it'd probably be *less* bulletproof,
since I wouldn't have absolute control over it, or not *as* absolute).
 
> >> dammit, and your client can most definitely make use of forward and back
> 
> >> while I'm playing if you use an interface that uses that -- like a
> separate
> >> help window on the side in a frame, for example. Browser-based clients can
> >> provide a lot of functionality and a lot of convenience, and I see a lot of
> >
> >Actually, I can't think of any extra functionality that could be offered
> >by a Browser based client. Could you give some examples? (Genuine
> >interest). How would you find it more convenient?
> 
> Consider a framed site, with the terminal session in one frame, a table of
> contents in another, and the help file in another. I can browse the help

Interesting that you mention this; I intend to allow 'split screens' via a
separate communication protocol (the mud can send information to the
client for display in a separate window, do clickable menus, and so
forth). This would allow this effect to a point; but yes I see what you
mean. Otoh, I can only work in one terminal at once, and I don't really
mind having my screen spammed while I read files (although being able to
read *mail* in a separate window would be very nice).

> and news and all that while I play, without spamming the hell out of my
> screen. Back and forward are useful there. Someone else could design an
> add-on product which sat on top of yours, and just run it in a separate
> frame or window. If I play several games like this, I could fit two or more
> in the same browser window.

Well, you could always run multiple instances of a client program for the
same effect. ;)

> I could write Java and JavaScript that
> interacted with the world, or even use dedicated client software of some
> sort ot add to it. The availability of the 'chrome' is sometimes essential
> for this sort of thing, and the resources the chrome actually takes up are
> miniscule. After all, you have the whole application loaded anyway. 

Hmm. Can you anymore add to a client embedded in a webpage than you can
one which is an application? They'd both just be compiled classes. Unless
you mean adding other things to the webpage, of course. :)
 
> >It's not the only argument; just one consideration. And you may not wish
> >to use the entire machine up for your mudding! 
> 
> I should certainly hope not, but all the same you shouldn't be thinking
> about the 640K barrier when you build a client. ;)

I think I went over that already. :p
 
> >You might want to run it in
> >the background, or low-priority rather than in a browser (I think you must
> >accept that browsers are fairly huge things, now).
> 
> Browsers are also absolutely essential to most online activity. I think a

!!! The last application I ever tend to run is a web-browser. And then I
typically use lynx for a few minutes (partly because I don't have enough
*colours* to run Netscape reasonable due to my video card).

> larger number of people than you realise have their web browsers open all
> the time *anyway*. I've got three Netscape windows open as we speak. Plus a
> pair of NetTerm sessions to shell accounts and three MUDs. If I could do
> all of those in the browser, I would SAVE resources, since the browser
> would have a significant amount of shared code between windows.

This I'll accept as one point (and another reason why playing the
'resources' card is iffy, since it varies from user to user).
 
> >There are many machines below average. Personally, I own a p133 (intel),
> >with 5gb total storage space (not all available currently), and two
> 
> >cd-roms (4x and 2x). The video card has 1mb ram, and the sound card
> >doesn't work. It also has 64 mb ram (oh, and the CPU only clocks 100
> >because the PSU is overloaded by the SCSI bus). The 4x cdrom is kinda
> >busted, too. None of this is likely to change any time soon - I make the
> >assumption that I am not the only person behind what some people consider
> >to be 'standard'.
> 
> The system that cost $1500 last year (I just did some research on this
> recently) was a P133 with 32 megs and a 2 GB hard drive. 2 megs of video
> RAM was standard. A 4xCD was about standard. In other words -- yes, you are
> average. Better, in some respects. You have more RAM and disk than most
> people.

It probably averages out; the multimedia aspects of the machine are nearly
non-existant, because I rebuilt it with Linux in mind, and am not a gamer
(meaning Doom, et al).
 
> >The more resources the browser uses, the fewer are available for my client
> >if I wish to make it do clever and/or attractive things, though.
> 
> But some of those resources are things you can use yourself. Like the GIF
> and JPEG display code, the scripting engine, the document object model, the
> protocol support... you could actually use an SMTP mail server for your
> users and an IMAP mail interface on your back end. There's a lot of
> rendering code handled for you there, and it's that much work you don't
> have to do. And your users already have all their preferences set up, and
> all their druthers accounted for, and they already know how to use it. All
> in all, using the browser could be a really big design win if you leverage
> the technology right, and can actually SAVE memory and disk space.

A lot of this is already available and useable very simply in Java (one
reason which contributed to my selecting it). The only thing missing
currently is sound (not something that really jingles my bells anyway; but
it might be nice in the future).
  
> >This is no different to instally any other substantial piece of software.
> >Btw, AFAIK no reboots or anything of that sort are actually required to
> >get JRE running on windows (certainly was not needed when I test installed
> >an old copy of JDK 1.02 I had on the windows machine here).
> 
> When I last installed the JDK, I had to manually enter several environment
> variables and registry keys. It was not something I'd wish on a novice.
> I've also never had to do that with any piece of software I have ever
> installed, with the exception of the Gnu Win32 utilities which required a
> similar setup. (I think it's a UNIX thing. UNIX people seem to have this
> idea that you should have to prove you're worthy to run their software. So
> they make you do fifty weird technical things, and if you can manage that
> then you must know what you're doing.)

I didn't even have to do this with my Linux installation. Unpack, make a
few symlinks, party.
  
> >It could also be pretty hard to integrate Java and Javascript in any way
> >like this (as far as I can see). The trouble with JS really is that its a
> >scripting language which was (as far as I can tell) intended for embedded
> >objects in webpages, rather than 'dynamic objects' like Java itself.
> 
> Netscape has a specific connectivity option (LiveConnect) between Java and
> Javascript. MSIE supports it pretty well, as far as I can tell. Not like I
> use MSIE much.

Interesting.
 
> JavaScript is a lot more robust than it used to be. And on the Microsoft
> front, ASP in particular is an exciting technology. It's starting to look
> like I may never have to write another CGI script in my life. ;)

I must admit (again) being a bit JScrip ignorant; I've only read snippets
about it, and can't write it (I only do Java currently). I'm looking into
it, though. Another book I'd like to buy *sigh*
  
> >> What ever happened to single player games? I don't like team sports and I
> >> don't like competition and mainly I want something that I can play and have
> >> fun with even if there's no one else there. Most of the time there isn't
> >> going to be anyone else involved. (Sort of like my sex life.) This network
> >> game boom has really caused a lot of the single player stuff to suffer.
> >
> >Can't a lot of muds be played single-player (this is an interesting
> >notion).
> 
> Yeah, but they suck. I've tried. ;)

Heh. Roguelike games? ;)

--
Regards,
	-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html