The majority of new functionality such as searching for users in ICQ should be done in EBJava. Let the server alone to sit around cycling through forwarding stuff.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, one connection with all of the commands and communication going through that connection to be relayed through the server to where they need to go as they are now. For instance, adding buddies is done in a message generated in the client and only relayed through the server.
One of the people I talked to before I started working on this said that he had tried something similar and found huge scalability problems with the server. He said basically to put as much processing into the client as possible with the exception of logging on because that can tend to be a time sensitive thing.
It's up for debate, I guess, but my instinct says to follow him.
~Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Incidentally, I had always intended that the server be able to be run on the same computer as the client, so you could distribute it as an application that launches the server, binds it to a random high port, and then launches the front end all transparently to the user.
I just think that a very lightweight server acting only as a relay is a good way to go.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The majority of new functionality such as searching for users in ICQ should be done in EBJava. Let the server alone to sit around cycling through forwarding stuff.
I thought part of the point is that the client could be behind a rather restrictive firewall. Shouldn't there be just one connection to one server?
Yes, one connection with all of the commands and communication going through that connection to be relayed through the server to where they need to go as they are now. For instance, adding buddies is done in a message generated in the client and only relayed through the server.
One of the people I talked to before I started working on this said that he had tried something similar and found huge scalability problems with the server. He said basically to put as much processing into the client as possible with the exception of logging on because that can tend to be a time sensitive thing.
It's up for debate, I guess, but my instinct says to follow him.
~Chris
Incidentally, I had always intended that the server be able to be run on the same computer as the client, so you could distribute it as an application that launches the server, binds it to a random high port, and then launches the front end all transparently to the user.
I just think that a very lightweight server acting only as a relay is a good way to go.