[q2x] Refactorization

[Brian Hook]

> I'd suggest that the current naming convention, "Q_" is sufficient,

Ok.

> So, there seems little point trying to abstract generic client
> server architecture or other libraries. 

The abstraction isn't to make it more generic, it's actually just to 
enforce barriers between the subsystems to avoid unnecessary 
comingling and assumptions.

> To that end I'd suggest the
> names: "QCORE", "QCLIENT" and "QSERVER" with QCORE containing as
> much common code as possible.

The stuff shared between the client and server is really it's own 
thing because it's used by the built executable and not the DLLs.  
This is why there isn't a single monolithic lib that is shared + 
common.

So we're still looking at four separate projects: QCLIENT, QSERVER, 
QCORE (everything) and QCOMMON (client and server)?

> In time most of the QSERVER code will migrate to Lua and the client
> and server libraries will become less dependent on Q2 nomenclature
> and objects

Actually, I think QSERVER will stay how it is, and most of the game/ 
code will end up becoming Lua.  QSERVER is more engine-level server 
code (i.e. not game specific).

> objects have been migrated it will be easier to abstract a cleaner
> client-server engine which could handle different types of game,
> however the technology of Quake is fairly directed at interior
> games and so there would seem little point.

The important thing is to handle different types of games within the 
genre.  To make a really comprehensive mod requires hacking the client 
and server executables, not just the game DLLs.  Q3 fixed this with 
QVM and I'd like to see Q2X eventually get to that point as well using 
Lua.

> Since the code will be migrating to Lua this brings into play the
> Lua binding, where will this live? I think Brian mentioned that he
> didn't want Q2X to become dependent on Lua alone (from the depths
> of my scattered memory!), rather that it should be possible to
> embed other languages. If this were the case perhaps we need client
> and server binding libraries?

In a perfect world that's what i'd like to see, because there are 
other languages I could see being used as well such as Ruby and 
Python, but it's not a priority.  

The way I've envisioned it is that the server is game agnostic, it 
simply loads up the appropriate game DLL which can either be a 
directly executable DLL (as it is now) or it may just be a thunker, 
e.g. you'd make "gamelua.dll" and it would translate calls from the 
server to the Lua code.

> could be refactored. From experience I don't know why you'd want to
> do this as Lua is incredibly flexible, efficient and more than
> adequate for the usage of this project. 

My biggest gripe, honestly, is that Lua doesn't have real-time GC and 
it's not typesafe.  This can make larger scale projects a bit more 
tricky than I'd like.

Brian