Designing
Considerations in the overall tool design are listed.
Consider:
- User input—If the user needs to supply information or make a decisions about tool actions, there probably needs to be a client tool.
- User feedback—If the user is expecting to get some sort of information or output from the tool, there probably needs to be a client tool. (This aspect might be negated if the user can be emailed the feedback.)
- Performance issues.
- Network—If there going to be a large number of database transactions and/or large amounts of data, it would be best to have this work done on the server.
- Disk Usage—Servers are generally a better choice for creating large files
- CPU and Memory Usage—If the tool is going to need large amounts of either of these, the work is generally best done on the server.
- Access to necessary files—If there are supporting files that aren't accessible to the local machine, a server component will be needed.
- Time to complete the tool—Tools which will take a long time to complete should be run on the server.
- Interaction with other systems/software—This might include accessing other databases, running publishing software, or creating files to be 'picked' up by other systems.
- Scheduled tasks—If the tool needs to run on a scheduled basis (e.g., every night) in order to perform a server-based task, a command-line tool should be used.
- Remote Access—If a user needs to run a tool from a remote location and only has telnet access, a command-line tool would be the solution.
- Need for additional perl modules or other files to be installed and supported—It's easier to add modules or files to a server, since there aren't the distribution problems that come from having to install files on multiple PC's.