Does it need 2 GUIs, one for local and one for RMI

[Aruneesh Salhotra]

I am done with the data part of the URLyBird. I am starting on getting the design work and hooks for networked and local approach.

I feel confused when it comes to networked approach.

In network approach, it seems the client GUI needs to be connect to the server, which is holding vector format of the DB file, through RMI.

So there is a client GUI that is required.

For the server, you should be able to change the file name, and other aspects, like RMI listening port number. So that means thats the server GUI.

What can we do about this.

[Aruneesh Salhotra]

Excuse me, but I wanted to know if it requires spawning two GUIS in networked mode.
Also I dont understand "The GUI and Database elements must run in the same VM in local mode".

But in case of RMI, does it imply to have 2 VMs.

Essentially I think both RMI server and client should be two different threads in the same VM. RMI server would work in sync with the DB elements and RMI client would work in sync with GUI.

[Andrew Monkhouse]

Hi Aruneesh,

In local mode, there will only be one JVM - that is, the user will type java -jar runme.jar alone which will spawn only one JVM, and you will have to configure the location of the database from there, then start booking records.

In networked mode, there will be two separate JVMs. The user will type java -jar runme.jar server which will spawn the first JVM where you can configure the database location (and ports and anything else you want to configure). Seperately the user will then type java -jar runme.jar which will start the second JVM where the user will provide any necessary information to connect to the server (IP Address / port / ...).

Does this help?

Regards, Andrew

[Aruneesh Salhotra]

This really helps a lot. It was driving me nuts, just that I am not a well versed person when it comes to JVM.
It really takes so much confusion off my shoulders, as I was thinking that the RMI server and RMI client, were going to be in the same JVM in networked mode.

[Bob Nedwor]

Yes. Thanks, Andrew. This helps me out, too. I was wondering how the system is supposed to know which of the 3 things the user is trying to do. I need to re-read the specifications more closely.

Looking forward to getting your book.

[Bob Nedwor]

Andrew:
I have only written a couple small RMI programs, just to get the basic concepts, but how does this strategy sound?

1) When the user types "java -jar runme.jar server", a message comes up with the ipaddress of the machine and tells the user to use it when asked by the client program (plus all the other stuff the server is supposed to do).

2) When the user types "java -jar runme.jar" on a different (or the same) machine, the user is prompted with something like "enter the ip address provided by the server program" (plus all the other stuff the client prgram is supposed to do).

I would be afraid to assume that the user is going to use the same physical machine, but then again I don't think there is a "must" about this one way or the other.

Thanks for any hints.

[ February 16, 2006: Message edited by: Bob Nedwor ]
[ February 16, 2006: Message edited by: Bob Nedwor ]

[Eiji Seki]

Hmmm, I'm not sure, but I think you should avoid command-line input in the client side. GUI configuration of the server address seems safer (not to loose GUI points). I like the idea of starting with default address as localhost (assuming no old configurations were loaded), but allowing the user to change the data store server.

[Aruneesh Salhotra]

I am designing the application in a way that the startup depends on the property file. If the application is started in local mode, it is simple.

In case of network/client operation, if DB file and rmi address/port is not present, it will ask the user with an inputbox about the information, with default values there in the text fields.

Once that phase is complete, the applications starts up.

On next restart, they are read from property file.

[Bob Nedwor]

Yes. Thanks to both Eiji and Aruneesh. Don't worry. I was not thinking about a command line prompt, but rather a prompt within the GUI. Either way, there is no way we can predict what the ip address of the computer, running the server portion, will be, or determine it programatically.

Yet, I think it is still reasonable for us to plan that that the program needs to work across physical machines.

Unless, I am missing something else, one way or another we need to get this info from the user. Aruneesh's solution seems great, but "will it be allowed by the evaluator?" is the question. I guess I will find out more when I receive Andrew's book from Amazon in a few more days.

Thanks so much for your help on this.

[Pankaja Bansal]

If I understand it correctly, can anyone please confirm that in case of local mode, there would be only one single JVM running both Database and Client.
In this case, there would be one and only one user at a time accessing the database. Or do we have to take care of the situation where two users on the same machine but in different JVMs (both in local mode) are accessing the same file. In this case there seems to be no way to synchronize the writing/reading operations on the file and there can be inconsistency. Am I right ? Are we expected to handle this situation ?

[Eiji Seki]

Originally posted by Pankaja Bansal:
If I understand it correctly, can anyone please confirm that in case of local mode, there would be only one single JVM running both Database and Client.
In this case, there would be one and only one user at a time accessing the database. Or do we have to take care of the situation where two users on the same machine but in different JVMs (both in local mode) are accessing the same file. In this case there seems to be no way to synchronize the writing/reading operations on the file and there can be inconsistency. Am I right ? Are we expected to handle this situation ?

At least in my spec it clearly states that when running in standalone mode (non-network mode), the server and the client should run within the same VM and must perform NO networking (and a few more restrictions).

Notice that in this case the data server does not even allow other connections. But you can always have the test case of a VM running in server mode and one, two, three or more VM's running clients, all in the same machine. So be careful when you say "local mode", because that could mean also connecting to the local host.

About the concurrent file access, I guess your spec contains, as mine does, this text: "You may assume that at any moment, at most one program is accessing the database file (...)". I guess that answers your question.