March 1998
- Describe Concept Stephen Zepp
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Jon A. Lambert
- Describe Concept J C Lawrence
- Describe Concept Vadim Tkachenko
- Tutorial: Let's build a Compiler! - Part XI: Lexical Scan Revisited Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XII: Miscellany Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XIII: Procedures Jon A. Lambert
- Tutorial: Let's build a Compiler! Chris Gray
- VEIL Network Protocol Brandon Gillespie
- Tutorial: Let's build a Compiler! - Part XIV: Types Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XV: Back to the Future Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part XVI: Unit Construction Jon A. Lambert
- For Ling's FAQ Koster, Raph
- MUD Ratings jlsysinc.ix.netcom.com@ix.netcom.com
- Random Generation Tools Ling
- ANNOUNCE: DB Robin Carey
- THE DARKWHOLE TESTS J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor J C Lawrence
- Magic as Metaphor Jon A. Lambert
- Magic as Metaphor J C Lawrence
- CT - A Hypothetical Session (mid 1995) J C Lawrence
- 2Cyberconf: An article J C Lawrence
- (long) AnarchyMOO Primary Log J C Lawrence
- (short) AnarchyMOO parting salute J C Lawrence
- AnarchyMOO purpose J C Lawrence
- (fwd) CODE RELEASE: [client] Spod! (Java mud client) J C Lawrence
- (fwd) CODE RELEASE: [client]: lyntin (hacker's client) 1.1b Released J C Lawrence
- DarkWhole Test #1 J C Lawrence
- DarkWhole Test #2 J C Lawrence
- DarkWhole test #3 J C Lawrence
- DarkWhole test #4 J C Lawrence
- DarkWhole test #5 J C Lawrence
- DarkWhole test Identity Crisis J C Lawrence
- The Craft of Adventure J C Lawrence
- What in THE Hell was that? Stephen Zepp
- What in THE Hell was that? Ben Greear
- What in THE Hell was that? J C Lawrence
- What in THE Hell was that? Jon A. Lambert
- (fwd) Varying Time Commitment Levels: what's an admin to do? J C Lawrence
- Hello, and a brief intro cimri
- Hello, and a brief intro Ben Greear
- (no title) Time limits? s001gmu@nova.wright.edu
- (no title) Time limits? Justin McKinnerney
- (no title) Time limits? J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars Jon A. Lambert
- Speaking of Avatars J C Lawrence
- Speaking of Avatars Jon A. Lambert
- Re: Vadim Tkachenko
- META: Broken mail headers coder@ibm.net
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Alex Oren
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Chris Gray
- META: Broken mail headers J C Lawrence
- META: Broken mail headers Caliban Tiresias Darklock
- META: Broken mail headers Chris Gray
- Turn-based MU*'s Sauron
- Balancing Addicts -> soft vs. hard enforcement cimri
- Balancing Addicts -> soft vs. hard enforcement Justin McKinnerney
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Ling
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement J C Lawrence
- Balancing Addicts -> soft vs. hard enforcement Jon A. Lambert
- Balancing Addicts -> soft vs. hard enforcement Matt Chatterley
- Balancing Addicts -> soft vs. hard enforcement Adam Wiggins
- Balancing Addicts -> soft vs. hard enforcement Joel Dillon
- SfD: Clientside Caching Nathan F Yospe
- 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@ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\-- - SfD: Clientside Caching Nathan F Yospe
- SfD: Clientside Caching Chris Gray
- SfD: Clientside Caching Jon A. Lambert
- SfD: Clientside Caching Jon A. Lambert
- (subject missing) J C Lawrence
- Balancing Addicts Ling
- Balancing Addicts Richard Woolcock
- Balancing Addicts Ling
- Balancing Addicts J C Lawrence
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Jon Leonard
- Transport layer (UDP vs TCP) Ben Greear
- Transport layer (UDP vs TCP) Chris Gray
- Transport layer (UDP vs TCP) Niklas Elmqvist
- Transport layer (UDP vs TCP) Jon A. Lambert
- Transport layer (UDP vs TCP) Ben Greear
- Time Limits? Jon A. Lambert
- META: topic and thread culling (was Balancing Addicts -> soft vs. hard enforcement ) J C Lawrence
- (subject missing) J C Lawrence
- XShipWars J C Lawrence
- (fwd) INFO: [client] Chaco looking for new parent for Pueblo J C Lawrence
- SIMULATING FUTURE HISTORIES: THE NAU SOLAR SYSTEM SIMULATION & MARS SETTLEMENT J C Lawrence
- (fwd) Functional Security J C Lawrence
- (fwd) Functional Security Ling
- (fwd) Functional Security Chris Gray
- (fwd) Functional Security Matt Chatterley
- (fwd) Functional Security Miroslav Silovic
- (fwd) Functional Security Felix A. Croes
- (fwd) Functional Security J C Lawrence
- SIMULATING FUTURE HISTORIES s001gmu@nova.wright.edu
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis Casey
- Character development [was ] J C Lawrence
- Character development [was ] Travis S. Casey
- Character development [was ] Marian Griffith
- Character development [was ] Travis S. Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Travis Casey
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] Vadim Tkachenko
- Character development [was ] Marian Griffith
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Marian Griffith
- Character development [was ] J C Lawrence
- Character development [was ] Cimri
- Character development [was ] J C Lawrence
- Character development [was ] s001gmu@nova.wright.edu
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Caliban Tiresias Darklock
- Character development [was ] Vadim Tkachenko
- Character development [was ] Ben Greear
- Character development [was ] Matt Chatterley
- Character development [was ] J C Lawrence
- Character development [was ] Matt Chatterley
- Character development [was ] Travis S. Casey
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] J C Lawrence
- Character development [was ] Koster, Raph
- Character development [was ] Alex Bertoglio
- Character development [was ] J C Lawrence
- Character development [was ] J C Lawrence
- Character development [was ] John Bertoglio
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs J C Lawrence
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Chris Gray
- 3D engines for MUDs Ling
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Mike Sellers
- 3D engines for MUDs Niklas Elmqvist
- 3D engines for MUDs Koster, Raph
- 3D engines for MUDs Ling
- 3D engines for MUDs s001gmu@nova.wright.edu
- Dynamic Loading of Modules Niklas Elmqvist
- Dynamic Loading of Modules Greg Munt
- Dynamic Loading of Modules J C Lawrence
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Vadim Tkachenko
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Chris Gray
- Parlez vous NPC? Matt Chatterley
- Parlez vous NPC? Nathan F Yospe
- Parlez vous NPC? Matt Chatterley
- Dynamic Loading of Modules Niklas Elmqvist
- Dynamic Loading of Modules Chris Gray
- Dynamic Loading of Modules Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Ross Nicoll
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? s001gmu@nova.wright.edu
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Joel Dillon
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Matt Chatterley
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Adam Wiggins
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Orion Henry
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Nathan F Yospe
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Vadim Tkachenko
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Greg Munt
- World Persistence, flat files v/s DB v/s ?? Ben Greear
- World Persistence, flat files v/s DB v/s ?? Jon A. Lambert
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- World Persistence, flat files v/s DB v/s ?? Chris Gray
- World Persistence, flat files v/s DB v/s ?? J C Lawrence
- Jukebox Vadim Tkachenko
- Another recruit for the list? Joel Dillon
- OT: Martin Keegan J C Lawrence
- Old code Joel Dillon
- Old code Michael Hohensee
- UML/Commercial v Free Muds Greg Munt
- UML/Commercial v Free Muds Nathan F Yospe
- UML/Commercial v Free Muds Jon A. Lambert
- Heightfield Terrain Rendering Paper Niklas Elmqvist
- (subject missing) J C Lawrence
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying s001gmu@nova.wright.edu
- (fwd) Roleplaying Katrina McClelan
- (fwd) Roleplaying Ling
- (fwd) Roleplaying J C Lawrence
- (fwd) Roleplaying Travis Casey
- Predicting future motion intelligently J C Lawrence
- META: New Mail server and ISP J C Lawrence
- (rec.games.mud.admin) Roleplaying (fwd) Nathan F Yospe
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Jon A. Lambert
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. Chris Gray
- Persistant storage.... My current idea. Ben Greear
- Persistant storage.... My current idea. J C Lawrence
- Persistant storage.... My current idea. Ben Greear
- UML & CORBA Greg Munt
- [MUD-Dev]: smoothing J C Lawrence
- [MUD-Dev]: smoothing J C Lawrence