This file is a list of things still left to be done in the client.  If you
have additional ideas for the client, please feel free to email me at
"koconnor@cse.buffalo.edu".


Finish telegram window.  Should be capable of sending telegrams.  Also, a
regex search window that allows a programmable search of the messages would
be helpful.

Unit censor window should be programmable in some way.  Selection by fleet,
location, type, etc. should be allowed.

** Revamp current queue scheme.  The client interacts with the server in a
purely synchronized manner.  That is, no command is ever sent until the
CPROMPT protocol is encountered.  This method is ideal for the smart tools,
because it eliminates the problem of commands being "swallowed" by
unexpected sub-prompts.  In addition, it permits a large number of mutually
unaware commands to be buffered in advance.  Unfortunately, this method
requires a significant amount of handshaking, which adds latency to the
connection.  Ideally, the queue scheme should permit programmable "burst"
and "synchronized" modes.  In this type of heterogeneous environment, user
commands could be "bursted", while the smart commands would remain
synchronized.

Add more entries to the options database.  The option database currently
doesn't have many options for the graphical map objects.  If the colors,
and sizes of the friendly hexagons/enemy hexagons/origin
decorations/current sector markings/sect markings/etc were in the options
database it would make the client more programmable, and more likely to run
well on various platforms.

Graphical map ruler bars - Suggested by Bernhard Reiter.  If a sub-window
within the map window contained coordinate numbers for the sectors, it
would significantly improve the quality of the information presented within
the display.

Options, Options, Options.  The client should have the ability to tailor
itself to the user somewhat.  There should be an option to automatically
update the database prior to a "smart" command and an option to
automatically update the DB after user commands.  Also, there should be an
option to disable the current scheme of automatically updating after
certain "smart" commands.  Options to alter the map window should also be
available.  Point and click options for changing to new-designation should
be added.  Also, the ability to change the sector sizes would be cool.  The
current command syntax may be getting a little over-burdened; new
point-and-click pull down menus would be helpful.

Parsers, Parsers, parsers.  There should be a parser for everything!

Features, Features, you get the point..  New smart commands such as PEI's
nova, and simu tools.  (I'm working on nova now..)


Fix problem with name in ship dump/censor window.


Foreach additions:
Foreach command should be able to work with ships/plane/units in addition
to just sectors.
Optionally, an arbitrary python expression should be available in addition
to the x1:x2,y1:y2 ?modif syntax.  (IE something like: 
foreach [x>=4 and x<=14 and y>=5 and y<=23 and mil==5] echo [sect]
in place of:
foreach 4:14,5:23 ?mil=5 echo [sect]
)

The [elpsn]sync command should be moved to sync[elpsn] - this way it will
fit in better with the command parser.


Database storage conversion.  Currently all entries in the database are
stored as ASCII strings.  The parsers should be changed to auto-detecting
the most appropriate type, and store it that way.  This will reduce the
overhead, data storage, and code size in the long run.

Add a runfeed command.  Add support for | (pipe) syntax.  Check for ! in >
syntax.  Also, it may be useful to avoid pre-checking for pipes and
redirects, in favor of using the standard server protocol.  (With proper
security checks of course!)  The idea is, that if the queue conversion is
ever completed, then no distinction will have to be made between possible
sub-prompts with |, and > characters, and real redirects..

Add a graphical map window move utility.  It should be possible to
point-and-click move commodities around.

Add an option to the database class that will allow for automatic "wake"
detection.  The idea is from a post about WinACE - basically, when enemy
ships move around, the old locations are stored and time stamped.  This
then gives the user the ability to see the ship's "wake".

Add a high detail mode to the graphical map window - Suggested by Bernhard
Reiter.  The idea is to show info like mil quantity, and detailed unit info
on the map window.  Obviously, the sector size would have to be pretty
large for this to work, but in combat situations this could be helpful.

Possible elimination of the updateDB method chaining - it may be
sufficient to always perform a check after End/flush methods in the Tk
interface.  The advantage to doing this, is it simplifies the code.  The
disadvantage, is that all commands will force a changes check..  However,
it may very well eliminate excess redraws, in which case it would be
beneficial..

The update countdown timer should only update periodically (but should
never show an incorrect time).

The cshow command should work for nukes as well.  (It should be more
flexible.)

Additional map windows should receive sector highlights like the main
window does.

Possibly move empDb.megaDB['updated'] to empDb.updateDB.  (The recently
updated database really has nothing to do with the main database, and the
code does do a little "side-stepping" to make it work.)

Redesign the way the chained viewer classes handle sub-prompts.  Currently,
the viewer classes pass the flush protocol along the chain via the flush()
method.  Later, the viewer(or a viewer class in between) will send the
answer to the server directly using a low-level write method.  Ideally,
some form of a coroutine should be passed along with the flush()'s current
parameters.  That way, this function could be called with the sub-prompt's
response, instead of resorting to a low-level server write.  The advantage
of this, is that it would allow the server to better handle "update
interrupts".  (IE.  the co-routine would be able to recognize when the
server isn't in sync and would just abort.)  Also, it would allow for an
Answer() method to be added to the chained viewer classes.  The Answer()
method would allow the chained viewer classes to peek in on what responses
are being sent to the server sub-prompts.  As another advantage, it would
permit entirely artificial sub-prompts to be created by client commands.
This type of conversion is probably a must before the final queue
conversion can be completed - without more sane handling of sub-prompts, it
will be difficult to track which sub-prompts have already been answered,
and which still require a response.


Perhaps design a more high-level approach to parsing composite command
output.  Right now, there is exactly one default parser defined per
command.  (A parser can be called by many different commands, but each
command currently has at most one parser.)  Although this is ideal for most
commands, certain output is duplicated in multiple places.  For example, a
map/bmap can be received from a M/B command at a nav sub-prompt.
Similarly, plane interdiction messages can be received during a move or
during a telegram message.  Obviously, it would be difficult to merge the
telegram and move parsers together - they for the most part have nothing to
do with each other.  Similarly, the map and navigation stuff really don't
have much in common.  Ideally, some kind of daemon viewer class could be
engineered that would direct output to sub-viewer classes.  (The sub-viewer
classes may or may not be viewer classes themselves..)  I would like to
break the viewer classes up into blocks of code that do primarily one
thing, and then design megaViewer classes that direct server output to the
other viewer classes when necessary.  For example, ParseUnits is the parser
for radar/lookout/navigate/march/etc.; ideally individual parsers could be
defined for radar, and lookout, and march/navigate would call those parsers
only when radar/lookout output is recognized.  This would certainly beat
packing all those parsers into one big class..


Move Tk specific client commands out of empCmd, and into empTk.  A generic
register method should then be added to the empParse class, and empTk
should call it to register the Tk specific commands.  This will help define
a better sense of object orientation.

Allow for dynamic binding of special key events.  Perhaps a command syntax
like "bind ^s sync" could be designed.  This has the advantage of making
the client extremely customizable and powerful.

Add a series of pull-down/popup menus to the client.  The "million-and-one
mouse binding" approach can only go so far.  (It has already gone too
far..)  By designing pull-down menus, the client will be more powerful and
easier to use/learn.

Design a queue editor functionality.  There should be some way to clear the
outgoing command queue.  Also, there should be a way to pause the queue.

There should be some way to manually re-open the login window.  That way,
it would be possible to change your country name/password on the fly.
Also, it would be useful for changing the country after logging in as
visitor.  In addition, it should be possible to force a disconnect from the
login window.  Optionally, it may be useful to allow a database reset from
there as well.

It would be neat if the client had a graphical display mode where the
sector designations were displayed using a set of bitmaps.

The map window should have a distinction between enemy units and owned
units.

The client should detect where the installation directory is, and use that
as a default before searching the current working directory for many of the
configuration files.
