[MUD-Dev] Re: Graphic design, client questions

[Jo Dillon]

Caliban Tiresias Darklock (caliban at darklock.com) spake thusly:
> I said:
> >  Hmm. a) surely you mean TCP/IP? Telnet is a protocol on top of TCP/IP;
> >it just so happens that you can use a telnet client to talk to ftp,
> >http and so forth servers, but that doesn't mean they really speak telnet.
> 
> They don't speak the options, certainly, but they do run over a telnet
> connection. While I have not read *all* of the RFCs in question, and don't
> feel like looking them up to confirm exactly where and what they explicitly
> say, many of them (I am tempted to say all, but I have to admit the
> possibility that one or more of them does not explicitly say this) actually
> say up front that they are constructed over a telnet connection -- with all
> the IAC negotiation that implies.

  I stand corrected, though it still seems slightly odd to me.
> 
> Seriously, boiling the internet down to one protocol is an exercise in
> futility. There are always significant parts which don't fit into that
> reduction. This is one of them. We certainly can't just chuck UDP out the
> window, but we can rather safely ignore it in many cases. Not all. Certainly
> not all.

  True - though I'd be tempted to build some types of mud client out of it.
> 
> >  Why not write a cross-platform client in something like wxWindows?
> 
> I am not a fan of cross-platform, but this is basically prejudice. A user
> interface guru once said that if you want a Windows app, build a Windows
> app, and Windows users will like it. If you want a Mac app, build a Mac app,
> and Mac users will like it. If you try to do both at once, you will really
> not be doing either, and it will just make both groups unhappy.

  Well, the really cool way to fix this is to have a themeable look
and feel - so that the application can rearrange itself to look appropriate
for each platform according to a config file.

> >  Java is /easier/ to set up as an applet.
> 
> But you have to set it up *every* time, because you never know if the user
> has set it up before. You could use a cookie, but cookies are supposed to be
> Bad for some reason which always escapes me. And besides, users can refuse
> or delete or modify cookies. ;)

  True. Using a signed applet lets you save configuration files, and of course
you can also suck them over the net (the applet I maintain for the company
I work for does both).
 
> I'm tempted to get into a language war here, because I absolutely hate Java.
> But instead, I'll allow that it may not be a *total* piece of garbage -- I
> just don't find that it suits my needs, ever. As a developer, as a user, it
> doesn't matter. Java has never been a reliable or acceptable solution for a
> native app in my experience. YMMV.

  Actually, I tend to agree. It's ok for small dialogues and things but I
wouldn't want to do anything complicated in Java. I should know, I maintain
a 30,000 line applet which is horribly slow and has some graphics
glitches which are a nightmare to get rid of. That's why my preference
would be for a native-code cross-platform client :)

--
	Jo