[MUD-Dev] SfD: Clientside Caching

[Jon A. Lambert]

On 18 Mar 98 at 15:31, Nathan F Yospe wrote:
> On Tue, 17 Mar 1998, Jon A. Lambert wrote:
> :On 16 Mar 98 at 17:20, Nathan F Yospe wrote:
> 
> :I find the heavy use of native methods intriguing.  Certainly it's
> :possible to write a great deal of client code in C/C++ that's highly
> :portable.  And let the Java VM handle the OS dependencies.  While it 
> :might not give you the highest performance gains in the areas you 
> :probably need, it is attractive from a maintenance standpoint.   
> 
> This is a big part of it, and something I wouldn't mind doing. It isn't
> what I meant, precisely; on the Mac, for example, I have my own version
> of the awt that taps into a couple of the newer drawing methods and even
> quicktime 2.5 or 3.0, if present. I'm planning to do this for Windows in
> time, and eventually possibly for other machines. I haven't learned enough
> about BeOS to do this effectively yet, and frankly, don't like the stuff
> available with X or Motif, and would prefer to leave that to Java. 

This is exactly the code I also want to leave to "third-party" 
widely available libraries, VMs, APIs.  I have no desire to delve 
into the inner workings of gadgets, components, toolboxes, windows, 
buttons, etc.  However one expects that the performance and methods 
available to do complex graphics within these windows has a level of 
"industrial" or "commercial" strength behind it.  These types of 
components are tightly coupled to their OS APIs, contain the vast 
majority of errors, and are difficult to maintain.  This is exactly 
the level of coding I want to leave to my vendor, whether it be a 
Java VM, Motif, whatever.  

Quicktime, as you mention IS an industrial strength option that I 
trust to perform and be maintained/supported on a wide variety of 
platforms.  It's a proven technology, as it is heavily used by Win 
and Mac graphical game producers.  

> However...
> a lot of the biggest stuff in the client, background graphics display aside,
> is text parsing and generation. The neural net code for that is all native,
> for good reason; it also happens to be nearly 100% portable. I'm still
> working on the portability of the tables associated with it.

Yes this is exactly the the type of code you should expect 100% C/C++ 
portability out of.   99% of this code is ADTs and pure C.  One would 
expect even standard library calls are infrequent and could be 
limited to minimal ANSI compliance.  An OS dependent call would 
be a rarity indeed.

The point I was trying to make is that when someone decides to sit 
down a write a Java client, they might not pay very much attention to 
the use of native methods.  One tends to think of using a native 
method when a problem is encountered that appears to be intractable
or difficult in the parent language or has an obvious performance
problem.  When you are using Java, you are likely to find yourself 
writing code that is as elegant, easy and "to the point of the 
problem" as when writing C/C++.  Yet performance problems in Java are 
not as readily obvious from looking at the code.  There are loads of 
subtleties in the way that "Java does things" that make performance 
profiling infuriating.  Most of the time you find it way up the Class 
tree in code you can't and don't want screw with, or buried behind 
the black hole of the VM.  

The summary of my rant is thusly:

Use native methods in Java liberally with code that is non-trivial 
and OS independent.  Then follow your normal instincts with the
rest of the code.  

> Watercolors within a short range of the background color (which does change,
> and the text color with it for contrast), or, to be more precise, so far
> pieces of art based on ... well, check my web page in a week or two, under
> the gallery. I'll announce the reopening of my page, as there is going to
> be a major mud related section on it. In any case, so far I have a few
> hundred pieces of suggestive background, none of which has anything to
> indicate specificity, but all designed to suggest a certain mood, clime,
> and atmosphere. Day and night, storm and calm, of city, desert, jungle,
> forest, town, space, caves, corridors, habitats, suburban towns human and
> alien, oceans, islandias, rivers, ice, bunkers, warzones... most of the art
> is not production quality yet, but it ought to be VERY effective. 

I'm looking forward to it.  The philosophy (if there is one) behind 
web wallpaper likely parallels this.  You don't want the backdrop 
to distract you from the text, you want it to gently suggest moods or 
sensations while reading it.  BTW don't look at my web pages for any 
good examples yet.  I'm as clumsy and direct as the typical net nerd. 
Yet, I know what I like when I see it on others' pages.

Mental Note: Enlist well-fed artist. 

>I wanted
> to use it for Singularity, back when I first tried to tie that old Rom into
> a web based plugin server... but it will be a lot more effective with the
> dynamic text of Intergalactic War: The Singularity Myth. (The name is a lot
> more accurate, and should have been kept as the name for the original. I
> have done a lot of going back to original concept with this, and am glad of
> that.)

What are the current running titles of your projects?  You've had
several name changes since I've been on the list. ;)

> :Most of these images could be included in the client download and my 
> :guess(?) is they would be highly compact of their light pixel 
> :density.  
> 
> I can get an extremely effective 640x480 gif into 6k on average. :) And yes,
> an original set would come with the client.

This is so cheap, and zero bandwidth to boot.  I'm beginning to 
feel guilty about it.  :~  

> :> 1) What are we going to cache?
> 
[snip]
> :Fixed or mostly static text like help, documentation, histories, 
> :stories would seem to be good candidates, as well as mud mail and 
> :bulletin boards. Having the above items client-side would allow the 
> :user to utilize mechanisms for off-line reading and study.
> 
> There's a good point I hadn't thought of. Well, in a sense I had. Direct
> mail doesn't even have to go through the server, if both clients are on. I
> have allowed client to client communication in the design. 

Didn't think of client-to-client.  With that in place you could shift 
ALL user communication off-server, even in-game chat, tell, whisper, 
emotes.  Possible player security issues here?   Then again, the 
server need not acknowledge or process communications "spam". 
 
> (I have yet to
> finish implementing this, and have no idea how well it will work. I based it
> on DCC to some degree...) Large amounts of text (the dictionary and
> thesaurus) would be built into the client, in rewriteable files that will be
> periodicly brought up to date. This might allow easy translation to other
> languages. (The grammar is a totally modular component.)

Hmmm, also a potential savings of string memory.
 
 
> :[snip - security issues]
> 
> :Nod.  Lots of potential for client-side programming or preference 
> :storage.  In my case, and some others I'd imagine, there would be
> :a couple of levels to this user-memory data.  I would make a 
> :separation of user memory and character memories since multi-play
> :and simultaneous multi-play is a desirable option.
> 
> *nod* This is a good point. At the moment, I have several items that are
> character specific. Memories of names, a cross-ref for the language files (I
> scan the character lexfile first, then the character's jargon lexfiles, then
> the global lexfile), preference files (these are models, and not so much a 
> character specific thing as a set of preferences that can be applied to more
> than one character, loaded or unloaded for a given character, split for some
> introduced difference (this is my standard preferences WITH prediction on,
> this is my standard preferences WITHOUT...), and so on.

Another possibility is to ship compiling of an internal mud language 
off to a builder client.  Late bind the code to server side objects 
in the final compile phase.  Client-side offline coding and 
syntax-level compiles are possible.  This might be a high CPU item 
for some online programmed servers.    

> Again, a good point. At the moment, none of my models distinguish much
> between the nature of objects... this presents some problems with the idea
> of seperating storage method... but backgrounds alone are easy enough to
> deal with. If not cached, they are grabbed in sets (climactic) that tend to
> be grouped together.

On second thought, it would probably increase complexity of the 
client enough that any benefits are undermined.  KISS and a common 
method of caching might be more prudent.  

> :I can't understand the need (or desire) for this much backward 
> :compatability (back to telnet terminals and 286s).  It's not 
> :even reflective of the current mud playerbase.  This is more a 
> :reflection of the administrative userbase.
> 
> And your point? _I_ want to be able to use this thing myself, you know, and
> it isn't that hard to make a UI change in Java, which is all that is being
> done here. Think of it like this: how hard is it to write the text output
> UI? How hard to write the GUI UI? OK, now, which one is more effective for
> a quicky test case? 

I agree; for testing - yes, for server-side administration - yes.

But for player use definitely NOT.  Why do I feel this way?  I don't
want to make commonly available an otherwise inferior presentation to
an unsuspecting playerbase as compared to my desired or ideal 
presentation.  It would be unthinkable, if someone running an 
capable machine got hold of this text-only client and absolutely 
awful if they introduced their mud-skeptical friends to it.  

OK, I exaggerate a bit.  :P   I think first impressions are lasting 
though.

> I'm not saying I'm going to use the remote hosted dumb
> terminal model much, but... come on, how many of you prefer lynx to Netscape
> when just doing a quick check of deja-news? How many prefer vi to Word when
> just making a quick edit to a source file? And if I'm going to write it for
> myself, why not make it available for others who use telnet access accounts
> regularly?

I can guess at the poll results.

Mud Design List - Lynx - 75% Netscape - 25%
                  VI   - 95% Word     -  5%

And my target audience would say...

FRPG Convention - Lynx - 5%  Netscape - 70%  Huh?! 25%
                  VI   - 5%  Word     - 60%  Huh?! 35%

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--