1. server mode - I assume this just runs the server with no GUI???
(passing commandline option mode=server)
2. alone mode - I assume this runs the server and client in a non-networked environment??
(passing commandline option mode=alone)
3. no mode - I assume this means we are running in network mode and thus we are connecting to an already running server???
(not passing any command line option )
Does this mean that the 'server' needs to have a GUI component??
Does this mean that the user needs to be able to specify the location of a
'The program must allow the user to specify the location of the database file, and it must also accept an indication that a local database is to be used, in which case, the networking must be bypassed entirely'
Does this mean that the 'server' needs to have a GUI component?? otherwise following the statement that were not allowed to pass any extra command line parameters in, I'm not sure how the server would know where the database lives.
'and it must also accept an indication that a local database is to be used'
Does this mean that the user needs to be able to specify the location of a remote database?? if so I'm not sure how that would be achieved
My server does not have a GUI component
All configuration must be done via a GUI, and must be persistent between runs of the program.
In the case of the server, once the config data has been collected and the user starts the application, the GUI disapears, and a confirmation that the server is running is printed on the command line. To stop the server, the user must press ctrl-c.
Just to clarify, I see the collection of configuration data as a seperate step prior to running the application so no matter what mode I use, a dialog pops up asking for the relevant config data for that mode. If a suncertify.properties file exists, the fields are filled in with the data from the file.
How about having a GUI server dialog with start and stop buttons? When the start button is clicked, the server is started, and the start button is disabled, leaving only the stop button that can be clicked. When the stop button is clicked, the server is stopped and the server dialog disappears. It's more friendly than pressing ctrl-c.
I am also now making the assumption that if a remote database is to be used then the GUI will request an IP address and port no. Have you guys also made that assumption??
The mode is selected using the single command line argument that is permitted. Architecturally , this mode must use the database and GUI from the networked form, but must not use the network server code at all.
In some assignment requirement, server GUI is a must. My instructions.html reads:
quote: All configuration must be done via a GUI, and must be persistent between runs of the program.
If it's all deployed from the same jar (which I assume you have too) then your client app can perform the configuration, and it'll write to the same .properites file as the server would read.
Originally posted by Robert Konigsberg:
Why can't you use the CLIENT app to configure the server? If it's all deployed from the same jar (which I assume you have too) then your client app can perform the configuration, and it'll write to the same .properites file as the server would read.
Say client 1 is on machine 1 and server is on machine 2, I am just curious on how the server configuration can be done from client 1 machine. The requirement is that properties file MUST be present in the working directory where jar is deployed. When you deploy jar on machine 1 and have its own properties file, how is that client can configure properties on machine 2 where server is running? I am not saying that its not possible, but what if 10 clients want to configure the server properties file at a time and here again we want to deal with the "synchronize" concept . Nope. I think its better to have server its own gui and that when application is run in server mode we have only one GUI which configures local properties file rather than 10 different clients wants to configure from 10 different machines and their implications
I also added a shutdown button on the client. I documented in the user guide that when someone shuts down the server, one should tell all other users that they must disconnect.
So if client 1 shuts down the server, command goes from client 1 to server to shutdown and from there to all other clients which are connected to server?
Originally posted by Robert Konigsberg:
You're not catching what I'm trying to communicate. Configuring Client1 will only configure for that machine. Running the client software on the server will configure for *that* machine. That's the solution I implemented. In other words, there is no "synchronization" need. Don't forget, "CLIENT" has no specific meaning. I took it to mean "All GUI operations."
OK, I got it now. If you want to configure machine where server is running, we have to run the jar from command line in same directory in modes other than server so that client gui comes up and then configure it to write to properties file. When server is run in the *same* directory it can use that configuration. If we want to run the server in a different directory, then again we have to run the jar in client mode in that directory.
[ July 23, 2004: Message edited by: Robert Konigsberg ]
I am planning to architect the system with the following components
3. Database Layer
Now in network mode the GUI access's the server via the RMI Interface. In Non gui mode the GUI access's the servers code directly, bypassing the RMI interface altogether ( as per the spec )
Now in the spec SUN mention the following:
quote: The mode is selected using the single command line argument that is permitted. Architecturally , this mode must use the database and GUI from the networked form, but must not use the network server code at all.
Does this mean in non-networked mode my GUI has to access my Database layer directly and not access the server code at all. Or does it mean I must not use the Server RMI interface, but I'm ok to access the actual Server methods??