[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

45: Re: Just a bit of musing

[Full Header] [Plain Text]
From: Wout Mertens <Wout.Mertens@rug.ac.be>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 13 Mar 1997 14:28:59 +0100 (MET)
References: [1]
Organization: Kanga.Nu
On Thu, 6 Mar 1997 coder@ibm.net wrote:

> Well, given an SMP machine, with an OS that will intelligently distributes
> threads -- that all semi happens for free with me (its not quite so good
> as I try to minimise thread creations, as few to no current OS'es will
> migrate a thread across processors for load sharing).  On the other side,

I don't get this. You do NOT create new threads because few OS'es will
migrate them? I would say that's a reason to create new threads the whole
time.... Or what am I missing?

Wout.

s worthless. The server only sends contextl tags if it is determined that it is being accessed by my client. Once the client begins execution, only it knows the window sizes, colors and fonts available of the browser its running in. There is know need for the server to negotiate this with the client. In fact this would be quite a mess. For instance the following might be sent: [:T1 You are standing in the great hall of castle Grimm :] -- room description [:T2 There is a large oak door set in the south wall :] - exit description [:T3 A banquet table:] - object description [:T4 Lord Grimm stands before you :] - player description [:P0 <%H,%P>] - prompt configuration [:P1 <100hp, 200pp> :] - prompt [:B0 "Help %":] - button configurations [:B1 "Inventory":] This is simplified but the muds output is basically wrapped with context tags and the client determines the placement and use. The server and client only need to agree on what the general purpose of the tag is. All mud output is basically standard unless context is indicated, the abscence of context is also handled by the client. Session.Output("blah blah",context) JL