<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD-Dev] SfD: Clientside Caching -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Wed, 18 Mar 1998 06:05:13 +0000 -->
<!--X-Message-Id: 199803180604.AAA13920@dfw-ix5.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: Pine.GSO.3.95q.980310153234.4069A-100000@uhunix1 -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev] SfD: Clientside Caching</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00745.html">Previous</a>
| <a href="msg00747.html">Next</a>
]
Thread:
[ <a href="msg00729.html">Previous</a>
| <a href="msg00755.html">Next</a>
]
Index:
[ <A HREF="author.html#00746">Author</A>
| <A HREF="#00746">Date</A>
| <A HREF="thread.html#00746">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev] SfD: Clientside Caching</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev] SfD: Clientside Caching</LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Wed, 18 Mar 1998 01:07:18 -5</LI>
<LI><em>Reply-to</em>: <A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
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#ix,netcom.com /*\--
--/*\ Mud Server Developer's Page <<A HREF="http://www.netcom.com/~jlsysinc">http://www.netcom.com/~jlsysinc</A>> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00755" HREF="msg00755.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong>
<ul compact><li><em>From:</em> Nathan F Yospe <yospe#hawaii,edu></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00729" HREF="msg00729.html">SfD: Clientside Caching</A></STRONG>
<UL><LI><EM>From:</EM> Nathan F Yospe <yospe#hawaii,edu></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00745.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00747.html">Re: [MUD-Dev] Balancing Addicts -> soft vs. hard enforcement</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00729.html">SfD: Clientside Caching</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00755.html">Re: [MUD-Dev] SfD: Clientside Caching</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00746"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00746"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Transport layer (UDP vs TCP)</STRONG>, <EM>(continued)</EM>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<ul compact>
<LI><strong><A NAME="00763" HREF="msg00763.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></strong>,
Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Thu 19 Mar 1998, 08:18 GMT
</LI>
<LI><strong><A NAME="00778" HREF="msg00778.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Fri 20 Mar 1998, 03:06 GMT
<UL>
<LI><strong><A NAME="00779" HREF="msg00779.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></strong>,
Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Fri 20 Mar 1998, 04:28 GMT
</LI>
</UL>
</LI>
</ul>
</ul>
</ul>
</ul>
</ul>
</ul>
</LI>
<LI><strong><A NAME="00729" HREF="msg00729.html">SfD: Clientside Caching</A></strong>,
Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Tue 17 Mar 1998, 01:01 GMT
<UL>
<LI><strong><A NAME="00746" HREF="msg00746.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 18 Mar 1998, 06:05 GMT
<UL>
<LI><strong><A NAME="00755" HREF="msg00755.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong>,
Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Wed 18 Mar 1998, 23:18 GMT
<UL>
<LI><strong><A NAME="00761" HREF="msg00761.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 19 Mar 1998, 06:51 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00720" HREF="msg00720.html">RE: [MUD-Dev] (no title) Time limits?</A></strong>,
Justin McKinnerney <a href="mailto:xymox#toon,org">xymox#toon,org</a>, Sun 15 Mar 1998, 23:35 GMT
<UL>
<LI><strong><A NAME="00723" HREF="msg00723.html">Re: [MUD-Dev] Balancing Addicts</A></strong>,
Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Mon 16 Mar 1998, 19:50 GMT
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
