Re: [Indic-computing-devel] Re: NCST Indix Examined

[Arun S. <ar...@sh...>]

On Wed, Feb 20, 2002 at 01:16:27AM -0800, Arun Sharma wrote:
> Yes, the designers of X wanted to keep X to be nothing more than an
> image rendering protocol and they probably had a reason too (which I
> haven't found even after quite a bit of searching - would appreciate
> references to X design rationale - I already have the OReilly Xlib book).

Some more thoughts on this topic:

- Most of the X designers worked for comapnies that had a thin client
  (X server) and fat server (X client) ideology. So naturally, they were
  inclined to keep the X server simple enough to be implemented in cheap
  hardware - NCD xterminals etc.

  However, the design center (at least numerically) for X has shifted to
  x86 PCs running some form of Free UNIX.

- Advances in hardware technology also have pushed more functionality to
  the X server. To be fair, most of these have been in the area of
  "acceleration"

- I think we should consider yet another alternative to the ones we're
  discussing. That would be (Apart from):

  	1. client side library implementation (Koshy's proposal)
	2. server side implementation (IndiX)
	3. "Character -> glyph code" server 

  Basically, have an external process to the complex mapping between
  characters and glyphs. This is not very different from say XIM servers
  for CJK. This has the advantages of both 1 and 2, namely:

  	- Installing Indic software on fewer machines
	- Simplicity of the X server
	- No extension the protocol and keeping the spirit of the
	  X protocol (image drawing server)

  However, X has been often criticized for sluggish performance due to
  having too much stuff running in many different address spaces (X
  server, window manager, x client) and this will only add to the
  misery.

- Another point to consider - font selection in a unicode text buffer
  containing codes from multiple scripts. Communication overhead might
  increase, if the client has to query the server for the correct font
  for each of the scripts. In a server side implementation, this could
  be done with less network overhead ?

  	-Arun