Why is there a server in this system? It seems like the EBJ should work like any other messenger- client only. I'm not too excited about all of my messages (and possibly chat and a/v) going through yet another server. Seems like all of the protocols could be put into an applet or jar, and the remote servers communicated with locally.
The project is extra cool, though. Seems to work well.
Jeff
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The main reason for the server is that I didn't want to have to mess with security allowances at all. Java applets are allowed to connect back to the host from which they are downloaded, but to connect to any other host requires specific permission from the user. I thought it was a good thing for the average user not to have to worry about it.
At the same time having the server has many benefits. For one thing, the connection between the client and the server can be encrypted. It's not encrypted to the service, of course, but at least noone on your local subnet will be able to read the plaintext. Also, a key feature of EBJava was to let you store your settings (contact list) remotely so that it is accessible from anywhere in the world. This could be done and still have the applet connect the services directly, of course, but I just think the advantages of the client/server combination validate the idea.
~Chris Carlin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A client/server design for a project in this space makes sense as a means to split development work between UI work and protocol work.
Doing this is the first step towards exposing your abstractions so that other people can build on top of what you've done.
However, for a project, half-living since 1997, which does what you suggest -- namely package up everything in a client-side application, see http://praya.sourceforge.net/
I've been looking to get AOL and ICQ for free by writing a "EBServ" protocol module, and I peruse through the discussion now, in order to see if I can even get this thing up and running.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why is there a server in this system? It seems like the EBJ should work like any other messenger- client only. I'm not too excited about all of my messages (and possibly chat and a/v) going through yet another server. Seems like all of the protocols could be put into an applet or jar, and the remote servers communicated with locally.
The project is extra cool, though. Seems to work well.
Jeff
The server consolidates much of the functionality so that you don't have to download it to your browser every time you want to connect.
In addition, some of the services might not be accessible through a firewall - so the server can act as a forwarding agent.
Kurt
The main reason for the server is that I didn't want to have to mess with security allowances at all. Java applets are allowed to connect back to the host from which they are downloaded, but to connect to any other host requires specific permission from the user. I thought it was a good thing for the average user not to have to worry about it.
At the same time having the server has many benefits. For one thing, the connection between the client and the server can be encrypted. It's not encrypted to the service, of course, but at least noone on your local subnet will be able to read the plaintext. Also, a key feature of EBJava was to let you store your settings (contact list) remotely so that it is accessible from anywhere in the world. This could be done and still have the applet connect the services directly, of course, but I just think the advantages of the client/server combination validate the idea.
~Chris Carlin
Jeff,
A client/server design for a project in this space makes sense as a means to split development work between UI work and protocol work.
Doing this is the first step towards exposing your abstractions so that other people can build on top of what you've done.
However, for a project, half-living since 1997, which does what you suggest -- namely package up everything in a client-side application, see http://praya.sourceforge.net/
I've been looking to get AOL and ICQ for free by writing a "EBServ" protocol module, and I peruse through the discussion now, in order to see if I can even get this thing up and running.