[MUD-Dev] SfD: Clientside Caching

[Jon A. Lambert]

On 16 Mar 98 at 17:20, Nathan F Yospe wrote:
>
> SfD: Subject for Discussion. I decided to stir things up. It has
> been slow. I'm going to start posting these every few weeks, or as
> the impulse strikes me... just to get the juices pumping. Feel free
> to tear it to pieces.

Good. I'm running out of juices and in danger of posting something 
offensive.  This looks like a much more productive topic. ;)   

> Today's topic: Storage of data for a mud on a permanent or temporary
> basis. For now, I will assume a system that only works with a custom
> client, where 'client' means either a remote pure client, or a
> 'smart' client, like those employed (presumably) by UOL. (Is M59 a
> pure client? I'm pretty sure Pueblo is.)
>
> A little background: 
[Excuse my active snippage.]
>    There were several issues that I considered when deciding to
>    create this
> client. The first was portability. In the end, I decided to make the
> client in two forms; the first a Java GUI application with optional
> native methods for select platforms, the second a Java text
> application with output to the main terminal, again with optional
> native methods, to be hosted by the user on some unix account, here
> effectively giving them a way to play the mud as if it were a
> regular telnet server, with a telnet client. 

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.   

[snip]

> client on current resources, and I wanted, as a bonus, to be able to
> provide a GUI and background pictures for clients not running as
> telnet. 

Backdrops/backgrounds interest me.  Personally, I would find a client
quite attractive that included backdrops that represented simple  
terrain flavors.  For instance forest, desert, meadow or urban 
backdrops.  Unobtrusive backdrops, like smeared watercolors on light
canvas that would allow text to be easily read on top.  Sort of a
mood thing, abstraction is certainly an attractive possibility.  
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.  

[snip]

>    Essentially, the question of client caching comes down to 1) What
>    are we
> going to cache, 2) How long are we going to cache it for, 3) where
> and how, and 4) why do we need to cache it? This brings us to the
> technical portions of this discourse, and I will now try to break my
> inane habit of right hand justification. It's become an addiction,
> you see.
> 
> 1) What are we going to cache?
> 
>    There are several potential candidates for caching. Of course,
>    there are
> the obvious ones; graphics ought to be cached in memory, then on
> disk if a disk is available (this is not possible with applets),
> sounds ought to at the very least be cached on disk; anything else
> of similar size should, at all costs, be kept as far from repeated
> downloading as possible. Text, while less bandwidth intensive, might
> also be a candidate for caching. 

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.

[snip - security issues]

>    This covers well the storage of things from the server, but there
> is another potential here that I think is far more valuable: storage of
> those things inherent to the client's "memory"... be it name
> recognition, scripts and preferences, or a complete "personality" to
> be applied to text parsing or generation, having this on the
> client's end opens up a whole new level of potential. This is
> currently embodied by arcade fighting and racing games. Have you
> ever seen one of these games get tougher and "smarter"?

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.

> 2. How Long are we going to Cache it for?
> 
>    We've got a chunk of data; we want to be able to reference it
> without downloading it again; but we don't want to store it forever - unless
> we are doing the database thing, in which case we may go so far as
> releasing most of it on a CD and just storing updates 

I'm thinking in terms of forever for my client-side storage, but 
understand it's much less graphically ambitious an intensive than 
your project.  A client-side database updated at will by the server 
seems to be attractive.  

> (ref. UOL,
> M59?), or at the very least, notifying clients that the database may
> reach a size as large as X, where X is some number larger than what
> (you hope) is the maximum size in the reasonably foreseeable future.

Actually Nathan, wouldn't this growth aspect, with respect to 
graphics-only, be highly predicated on the method of generation 
and/or the use and types of graphics you send?

If one generates unique pictures, .gif's, .jpg's, anime .gif's etc. 
(that are likely artist rendered) to represent backdrops, objects, 
avatars, animation then the longest storage due to frequency of usage
or appearance might be attractive.  Storage requirements might 
also depend on the context of the objects' use.  Scenic/room 
depictions might be cached based on position locality, while 
creatures might be cached on frequency of appearance.

If one generates computer drawn images that may or may not depend 
upon a set of reusable pallettes and textures, one might want 
permanent storage for any reusable components and some other method 
for the drawing "instructions" that use them if its ray-tracing, 
BSPs, etc.   

[snip]

> 3) Where and How?
> 
>    This is not just a question of memory, disk, or register. This is
>    also
> one of access... if we are caching for the convenience of the client
> and server on downloads, we want it right there, but say there is a
> memory of some sort associated with the client. Does a player who
> uses many machines have to carry their memories on a disk? Why not
> allow a player to set some remote accessable point, in the manner of
> a remote .newsrc, that can be pointed to by multiple machines, with
> a breakpoint on time, or a SCCSlike diff function?

Yikes!  I would have never thought of portable clients in a million
years.  Do you really think this scenario likely or common?  Or is 
this one of those administrator-driven features rather than a 
player-driven feature?  Perhaps a simple method of backing up and 
restoring the user "memory" area would suffice.  I might be assuming 
that any graphic data in this area would be of the avatar-type or 
inventory-type graphic references?  Then again, with the advent of 
the "internet cafe" you might be on to something with public 
access terminals becoming as common as phone booths.  :)

> 4) why do we need to cache it?
> 

[no disagreement on the why do's!] 

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.    

--
--/*\ 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   /*\--