These are the items we have identified as potentially needing longjobs
development work in the future.  Items are rated for urgency (U),
importance (I), and estimated amount of effort (E), from 1 (least)
to 5 (most).  In some cases, the effort rating is more of a guesstimate,
since we haven't studied the issues in enough detail.

U   I   E   Description

5   5   2   don't allow group membership to be inferred

3   5  3-5  temp disk space issue

3   5  3-4  upgrade/merge PBS base, to OpenPBS 2.3 or PBSPro

2   5  4-5  more versatile scheduler (reservations, node-based queue limits
	    (aggregate or otherwise), predictable execution time), e.g.:
	    - Maui
	    - PBSPro
	    - use resources_available queue attribute somehow
	    - transmit sort order to server

2   4   4   better quota DB (Oracle) - importance dependent on scale of
	    service

3   3   2   quota system tweaks, e.g. clearer rules for supporting
            individual quotas different from containing group's default

2   3   3   default tokens

2   4   3   encrypt all network communications (currently only certain
	    transactions, e.g. involving credentials, are encrypted)

3   4   3   clean up "RPP" (UDP-based inter-server status) messages

1   4   3   general code clean-up, make suitable for incorporation into
	    OpenPBS (using PBSPro may complicate this)

3   4   2   address command namespace issues

4   5   3   support Linux slave (ops server port)

4   5   3   polish user documentation; create internal support documentation
	    (including policies and procedures)


The scale of any eventual service has a bearing on a few of these items.
If we were to make this open for widespread use, then it becomes more
important to implement a better database for the quota system, and a
more versatile scheduler.  We would then probably also want to go with
PBSPro, which supposedly scales better than OpenPBS.

For further discussion, see /mit/longjobs/doc/dev_est.txt.