NX: Contractor 2.3.1 Ambiguities in the Spec

[Guido Tapia]

Hi,
I've found a couple of ambiguities in the spec.
1) When you submit your assignment, each part (client and server) must be executable using a command of this exact form:
java -jar <path_and_filename> [<mode>]
But then later it goes on to say that there can only be one jar file.
Does this mean that we can specify the file for each mode? Eg "java -jar runme.jar Server" and "java -jar runme.jar Client"
2) In either case, the program must allow the user to specify the location of the database, and it must also accept an indication that a local database is to be used
We already have a command line argument that specifies if we are using a local database do we need to provide another method of specifying this.
Also when running the server, do we need to prompt the user for the db location? or should this just be set through the client?
Thanks

[Philippe Maquet]

Hi Guido,
1) Yes
2) I think the command-line argument "alone" means running in stand-alone mode AND using a local database
Regards,
Philippe

[Jim Yingst]

Also when running the server, do we need to prompt the user for the db location? or should this just be set through the client?
Both. When starting the server, you should be able to specify (IMO):
port
file name (path) for DB file
For the client, they should be able to choose
hostname for server
port
Optionally, you could also allow both to choose the RMI service name, if using RMI. Or leave that hard-coded; I'm not sure it matters.

[Guido Tapia]

Thanks Jim
But as much as I would have liked to have a server that takes in dblocation port ect we cant due to the assignment limitations.
In various places through the assignment we are told that we can only use one command line argument.
1) "The operating mode is selected using the single command line argument that is permitted."
2) "Your programs must not require use of command line arguments other than the single mode flag, which must be supported. Your programs must not require use of command line property specifications. All configuration must be done via a GUI, and must be persistent between runs of the program. Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory."
Which is no problem for the Client as we can take in all parameters through a GUI. but in the server specifying things becomes more difficult and i think its a horrible design to let the client set the db location for the server. I was thinking of when starting the server just having questions in the console like
- DB Location:<current db location>
Would you like to change this? (Y/N) But again I think this is horrible.

[Jim Yingst]

I have the same instructions - as I interpret them, for all three modes (yes including server) we can and must call up a GUI which allows configuration. I agree that this is a bad design in the real world - for a server you'd want a option to just use the values specified in a props file, or something like that. But while there is a props file, they say all configuration must be done via a GUI. To me, that includes server configuration.
Naturally we can try to make the config as quick & painless as possible. The program can read the last used values from the props file, display them and offer two button: "Use These Values" and "Edit Values". So most of the time the user can just hit the first button.

[Guido Tapia]

I'm gonna try and find a way of interrupting System.in and what im gonna do is something like this.

Server Initialising

Press Enter to modify Settings (wait 3 seconds)

If user pressed enter go into console setup otherwise continue server initialisation.

I think this could work. Just dont know if you can interrupt System.in, maybe I can just have a separate Thread waiting on System.in and after the timeout I simply ignore any user input although this would block the System.io.read hmmm, Gonna try to find a way of interrupting the System.io.read