NX: Mode Flag Confusion

[oli renard]

Hello, I have just received the instructions for the SCJD. The most confusing part is regarding the mode flag. The instructions state:

"Your programs must not require use of command line arguments other than the single mode flag, which must be supported. ... The mode flag must be either "server", indicating the server program must run, "alone", indicating standalone mode, or left out entirely, in which case the network client and gui must run."

What does this mean exactly? Does it means that if I want to run the application using the server, I first have to do this:
java -jar <path_and_filename> server
to start the server and then this to see the GUI
java -jar <path_and_filename>
Does it mean that if I want to run the application standalone, I just run this:
java -jar <path_and_filename> alone
and then this to see the GUI
java -jar <path_and_filename>
Or does the GUI appear regardless of which mode I use?
And does running this (without any mode flag)
java -jar <path_and_filename>
mean that the GUI appear and uses the server to read the database?
I am really confused about this. Can anyone help as this is very far from clear.
Thank you

[Terry Martinson]

This recent posting should help answer your questions.
TJ

[oli renard]

Thank you Terry,
I did read that recent posting, but I am afraid that it still did not make sense (I must be missing something, I think). I read Andrew Monkhouse's posting (January 07, 2004 03:58 am) where he wrote this:

So, if the user types
- java -jar runme.jar -server
Dispay the GUI for the Server (allow the user to enter port for RMI Registry, possibly enter local db path for the server, any other server configuration items).
- java -jar runme.jar -alone
Display the Client GUI ready to ask local db path
- java -jar runme.jar
Display the Client GUI and ask for the host + port for RMI connection

So if I understand correctly, in all cases the GUI must be displayed and the user must be prompted for connection details. But must the user be prompted for such details? How could Andrew come to these conclusions as using default values much surely be fine and prompting the user is not absolutely necessary. Or is it?
Thank you

[Terry Martinson]

Andrew knows!
He's been around here a while and from what I hear, is right 999 out of 1000 times. I actually saw that figure out in some posting, and while I believe it was somewhat in jest, I think it's pretty true.
Your quote:

So if I understand correctly, in all cases the GUI must be displayed and the user must be prompted for connection details. But must the user be prompted for such details? How could Andrew come to these conclusions as using default values much surely be fine and prompting the user is not absolutely necessary. Or is it?

Default values are great, and I use them as a default to show to the user. User may then type over them to choose what they want. For example, I don't think you would want to assume that your default value for a remote server or port for a remote server would always be what the actual user of the application would want to use.
Also, the following quote comes from my spec. I would guess you have something similar:

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.

This leads me to believe that the program should provide configuration functionality.
Good luck.
TJ

[Terry Martinson]

One additional point - I only use the default values if there is not a value already out in the property file. The configuration needs to be persistent between runs of the program, so if the user chooses a value in run 1, that should be the default value for run 2 rather than my original default value.
TJ

[oli renard]

Thank you very much Terry. This does clarify things. I did not mean to question Andrew's ability in any way, I was just wondering how he knew. Thank you for answering my questions.

[amchi gelo]

By "default values", do you mean things like server IP and port, and location of database etc?

Originally posted by Terry Martinson:
One additional point - I only use the default values if there is not a value already out in the property file. The configuration needs to be persistent between runs of the program, so if the user chooses a value in run 1, that should be the default value for run 2 rather than my original default value.
TJ

[George Marinkovich]

Hi Sanjay,

Originally posted by Sanjay Joshi:
By "default values", do you mean things like server IP and port, and location of database etc?

There are two ways to go with the suncertify.properties file when distributing your application. One way is to distribute the suncertify.properties file with your runme.jar executable. Another way is to distribute only your runme.jar executable. The first time your executable runs it looks for the suncertify.properties, but doesn't find it. This isn't a problem if you have code in your executable that contains default values for all the configurable items (such as server IP, port, location of the database file, etc.). When your executable is unable to find the suncertify.properties file it uses the default values to write a new suncertify.properties file. The user can then use your GUI editor to change any of the default configurable items as necessary.
Hope this helps,
George

[amchi gelo]

Thanks a lot George!
One more question. suncertify.properties file is just used for server configuration right? (and not for the client)
Sanjay

[George Marinkovich]

Hi Sanjay,

Originally posted by Sanjay Joshi:
One more question. suncertify.properties file is just used for server configuration right? (and not for the client)

No. I used suncertify.properties for both client and server configurations. My suncertify.properties file contained a superset of configuration parameters for all operating modes (standalone, server, and network client). In standalone mode the executable is interested in database file location. In server mode the executable is interested in database file location and port number. In network client mode the executable is interested in database server host and port number.
To make this a little clearer. When my executable is running in server mode on the server machine it uses a local suncertify.properties file to persist its configuration parameters. The executable running in network client mode on the client machine uses its own suncertify.properties file to persist its configuration parameters. The two suncertify.properties have the same set of parameters, but their corresponding values are likely to be different. This isn't a problem; the suncertify.properties file is just a repository for the configuration parameters that are persisted for the nearby executable.
Hope this helps,
George
[ February 12, 2004: Message edited by: George Marinkovich ]