Download Module v1.1 - DMS - February 2003 - by Bob Le Gob
**********************************************************

v1.1 is based on v1.0 but has been greatly enhanced. The
main changes are:

- The module now allows you to define which files should
be loaded and zipped in server memory, and which one
should be kept on disk.
This will require more memory on the server but will help
clients to quicklier download their files (.txt or .m3d
compressed files for example).


Code
****
- All functions have been documented in the code.

Editor part
***********
- This part has been completely re-written to allow the
two different registration systems. Except the fact that
I tried to use the same callbacks for both registration
systems 2D objects (I'm using an index with value 0 for
files to zip or 1 for files on disk. The index is sent as
a parameter to 2D callbacks to quickly know what has to
be done. It is used too to know on which ObjList to work 
through the use of the tabObjList table. And finally, it's
used to identify how each file should be handled regarding
registration), there's nothing special in this code.
- Just note that the Editor stores the files that'll be
registered on the server as 'fd_reg' or 'fd_regF' in the
DMI block of the module (as per the _RSregister() and
_RSregisterF() Scol functions). 

Server part
***********
- This part has been fully re-written to adapt to v3.0 of
the Scol language tutorial, and to take into account the
two different registration systems.
- IniDMI()
  Initializes the list of files to download on clients and
  registers these files on server.
  Basic clients handling callbacks are defined too. We have
  two actions (start & destroy) and three events (started,
  destroyed & ended).
- RegisterFiles()
  This function parses the module's DMI block looking for
  'fd_reg' & 'fd_regF' entries that were defined in the
  Editor and accordingly registers the file either in memory
  or on disk through RegisterFile().
  Just note that the server checks the existence of the files
  and that RegisterFile() stores the size of the files too.

Client part
***********
- This part has been a little bit re-written. The code is 
quite clear and doesn't need any technical explanation. The
description of the functions seems clear enough to me.
- Since v1.0, two events have been added: registerDownload
and registerFile. These have to be linked to the similarily
named actions of the GlobalDownload module. Their purpose
is to tell this other module that a new download is starting
(with the total size of files to download as link parameter)
and that a single file has been downloaded (with the size
of the file as link parameter). Both events and actions
are local ones and do not require client/server communication.


Encountered problems
********************
- BUG: The _checkpack() function seems to apply some kind
of strlowercase() function on a given file path. The bug
can easily be reproduced through the following line code:
  _fooS _PtoScol _checkpack "test1.test2.TXT";
The line code returns:
  test1.test2.txt
If the P type is provided through another way - like a 
file selection box, the _PtoScol() function preserves the 
case of the character string (so the problem is certainly
in _checkpack() ).
- BUG: zip() crashes with character strings of length 0. This
causes a Division By Zero error. 
- BUG: If you define a structure and use a function's name
to name one of the structure's fields, the function is no
more available to you: Bad Term error.