I'm a little confused with some B&S instructions. First, see these statements:
"The program must allow the user to specify the location of the database in both standalone and network mode and persist the db configuration details in suncertify.properties file."
"Must implement a network server functionality for the database system"
"Such configuration information must be stored in a file called suncertify.properties which must be located in the current working directory."
Please see if I got them right:
1) in the server program I have just to set the port the server will use, the data base location, and than I can start/stop it. (Properties file will have the keys: server.databaseLocation, server.port)
2) in the client program I to specify the server IP and port (Properties file will have the keys: client.serverIP, client.serverPort)
3) in the standalone program, I just have to set the local database location (Properties file will have the keys: alone.databaseLocation)
So, if I run the three modes in the same machine, I'll have just one properties file (in the same directory as the runme.jar), with the keys of each of the modes that were launched, right?
And I'm a little concerned about this: "must allow the user to specify the location of the database in both standalone and network mode". Network mode is the client or server?
Roel De Nijs wrote:Your analysis about the properties is spot-on
Nothing to be concerned about. If you implement the 3 points you mentioned in your first post, you'll meet this "must" requirement without any problem.
Roel De Nijs wrote:Nothing to be concerned about. If you implement the 3 points you mentioned in your first post, you'll meet this "must" requirement without any problem.
I am still a bit confused regarding the term "must allow the user to specify the location of the database in both standalone and network mode"...
If implemented as indicated in the 3 points above, the user (GUI user) cannot specify the database file. It is automatically retrieved from the properties file. I understood the term that way that the user must be able to change/choose (specify) the DB file inside the application.
In my (current) application the user can choose the DB file with a JFileChooser. But I have a problem: If the "server" displays it, the user does not get the dialog when he uses another machine (it's displayed on the server's maschine). But if you the JFileChooser is displayed on the "client", the wrong file system is used: the client's file system. But the server's file system should be the one to use.
Furthermore I think the term implies that the user can switch between DB files without (re)starting a (new) server.
What do you think about this?
Thanks in advance.
When you start the server application, the user will be able to choose database file location and port number (through a GUI). Of course it's normal that when a user starts the network client he can't change the database file location (server is already running on another machine). He just has to provide server address (host name or ip) and the port number
Ah, OK. I understand. I think that would be the best solution.
My approach came from a practical experience:
Imagine a server supports 2 DB files (which would not be hard to implement): USA and Canada. My idea was to support an online switching between this two DBs (so that the program must not be restared). Maybe a bit too complicated... :-)
Thank you very much for this great and very fast advice!
Lucas cotta wrote:which is a good resolution to start the application?
I did not start application in full screen. Also, instead of choosing arbitrary resolution (well, we never know max resolution of examiner's monitor ), I chose resolution relative to monitor's resolution (say half or 0.75 times the monitor resolution).
Jochen R. Meyer wrote:Imagine a server supports 2 DB files
I don't think this kind of thing is required for OCMJD