No Subject

>     It   tells the client what it sees.  Where it sees nothing
>     because it is   behind walls, it does not send map commands.  The
>     client knows for what   areas it has received map commands and it
>     only displays those.  Those   areas which are not mapped in, it
>     can display whatever it wants and it   doesn't need any
>     instructions for it.
> 

> Ahhhhh. I see. I don't think you explicitly stated that somewhers
> before :-)

Forgive me for not being clearer.  I'll post a second draft in a few  
days and try to explain this better.

> [although the server DOES "tell the client what to draw an
> when". you're just fiddling with semantics :-)]

Certainly it does ultimately for most clients.  But I think the  
protocol should work at a higher level of abstraction.  


For example, the SMTP protocol doesn't tell the receiver:  Here a few  
characters, show them in this order to this user when he or she logs in  
the next time.  Instead the protocol says here is a complete mail  
message, do whatever it is to do with mail messages -- even if that  
ultimately results in the same output in many situations.  On the other  
hand the VT100 protocol is just a series of commands to be executed  
immediately.

I think that is the primary difference between different positions  
here.  Some people argue for a protocol like e.g. SMTP which assumes  
and allows some understanding of the sent data by the client, like  
SMTP.  Others demand a protocol which is just a series of instructions  
to a relatively dumb client, like VT100.

> I guess that makes your method a bandwidth win, at the expense of
> some server time.

Why does this cost extra server time ?  


	Carl Edman