I guess I should post a hello there message since Chris has agreed to transition this project over to me. I've have a keen interest in moving EBJava forward. I like much of what has been developed to date and I'd like to get some of the following items accomplished in the near future:
1) Encryption - I'd like to examine the possibility of encrypting either the session to the EBServ server or (maybe even better) encrypting the text of chat messages end to end. (This would require an appropriate client on both ends of course.)
2) OO Re-design of both the client and server.
3) Move to an ANT based build system.
4) Server side communication - I'd like to re-examine the design of the EBServ connections to foreign messaging systems. (i.e. - would it be better to use existing libraries for communication with AOL, ICQ, etc?)
Mostly, I have no intention of moving away from Java as this is my preferred language. I've worked in a lot of different languages over the years and I'm trying not to have to learn any more. Let me know what you think, I'm interested in all ideas.
...Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
EBServ runs under FreeBSD.
There is a port of version 1.1.8 of the JDK available for FreeBSD, and I actually rewrote a lot of EBServ to make it compatible with 1.1.8.
Kevin, when working on EBJava and EBServ it is probably a good idea to go with 1.1.8 compatibility. It is not much different from 1.2 (Java2) except for Swing, which I think it would be worthwhile to avoid anyway. If I remember right, the only major change I had to make to go back from 1.2 to 1.1.8 was to access vectors with a different method.
When all platforms, particularly FreeBSD, have version 1.2 JDKs, it would be ok to code to that, but for now it doesn't really hurt to use the earlier version.
~Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have yet to get 118 working on my BSD box. If you have a little free time, please mail me at kwerle@pobox.com. I'll describe my problems (mostly it involves a missing lib, I think).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nothing is wrong with Make. ANT is just a cross platform 'Java aware' build solution. It functions much like Make does. Once again, I favor solutions that are Java based since that's where I'm concentrating my energies. (When you get old like me you have to focus!)
...Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ant is a part of the Jakarta Apache project. (Jakarta is the Java Servlet implementation that Apache and Sun are working on.) Which actually leads me into another option we could explore for the server side - Servlets. This is an area I've been actively pursuing at work.
>How old is old?
I'll turn 40, just after the turn of the next millenium.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Encryption was something I always thought would be a great thing. To allow encryption between EBJava and EBServ would mean that cleartext would not appear in your subnet where most sniffers would be waiting. I never got around to actually implementing any encryption, but the only real problem I think you would have is in the size of the applet... including some encryption libraries could be hefty and there isn't one that comes standard with the JDK.
For server side communications you might want to see if each socket is implemented in a seperate thread. I did a big threading overhaul that I don't think was ever complete, but it increased server speed significantly while lowering resources.
I also looked for existing libraries for communication, but didn't really find any for Java. There was one for Yahoo I found, but it wasn't documented that well so I whipped up the ICQ and TOC (AIM) clients you see there. One suggestion is that as of recently you can use TOC to get on to ICQ accounts, so I would suggest you replace my ICQ library with my TOC one.
I fully intended on moving the server to C someday, for reasons of performance, scalability, and the availability of libraries to access the services.
I also would discourage the use of Swing on the client. Yes, it would make a lot of things a lot easier and prettier, but it would require a whole lot of people to download the Java2 plugin, and in many situations that is not possible.
Guess that's it for now.
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>Encryption was something I always thought would be a great thing. To allow encryption between EBJava >and EBServ would mean that cleartext would not appear in your subnet where most sniffers would be >waiting. I never got around to actually implementing any encryption, but the only real problem I think you >would have is in the size of the applet... including some encryption libraries could be hefty and there isn't >one that comes standard with the JDK.
I'm not sure about the size of the applet if we add encryption. I'll check that out in a little test applet. It's been about 6 months since I worked with the encryption stuff. I don't recall what JDK it appeared in. Also, we could always deploy a base applet with add-on functionality to support additional features. That way only the users who want/need the add-ons will have to download them.
>For server side communications you might want to see if each socket is implemented in a seperate thread.
I'll check into this as I review the current code base. I don't intend on changing things much until we have the functionality and development direction down.
>I fully intended on moving the server to C someday, for reasons of performance, scalability, and the >availability of libraries to access the services.
I don't agree here. I think EBServ should stay in Java for platform portability reasons. If we stay in pure Java we stay portable; of course we can always use Java's ability to call into native libraries. I have some friends working on this.
>I also would discourage the use of Swing on the client. Yes, it would make a lot of things a lot easier and
>prettier, but it would require a whole lot of people to download the Java2 plugin, and in many situations >that is not possible.
Once again this is another trade-off. The plug-in is one way to attack the problem of not having support of Java 2 on a particular browser. Another option that I've been working with is Java Jump Start from Sun. This is a method of launching a full fledged application via a web browser. Kind of a hybrid between applets and applications. The good thing is once you load Jumpstart and get the application (or even applet) it gets cached on your machine and doens't require downloading again unless the application (or applet) has changed.
First things first though.
...Kevin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess I should post a hello there message since Chris has agreed to transition this project over to me. I've have a keen interest in moving EBJava forward. I like much of what has been developed to date and I'd like to get some of the following items accomplished in the near future:
1) Encryption - I'd like to examine the possibility of encrypting either the session to the EBServ server or (maybe even better) encrypting the text of chat messages end to end. (This would require an appropriate client on both ends of course.)
2) OO Re-design of both the client and server.
3) Move to an ANT based build system.
4) Server side communication - I'd like to re-examine the design of the EBServ connections to foreign messaging systems. (i.e. - would it be better to use existing libraries for communication with AOL, ICQ, etc?)
Mostly, I have no intention of moving away from Java as this is my preferred language. I've worked in a lot of different languages over the years and I'm trying not to have to learn any more. Let me know what you think, I'm interested in all ideas.
...Kevin
What is ANT? What's wrong with Make?
I had an early interest in EBServ, but I need to have Java running on my server before it becomes useful to me (FreeBSD).
EBServ runs under FreeBSD.
There is a port of version 1.1.8 of the JDK available for FreeBSD, and I actually rewrote a lot of EBServ to make it compatible with 1.1.8.
Kevin, when working on EBJava and EBServ it is probably a good idea to go with 1.1.8 compatibility. It is not much different from 1.2 (Java2) except for Swing, which I think it would be worthwhile to avoid anyway. If I remember right, the only major change I had to make to go back from 1.2 to 1.1.8 was to access vectors with a different method.
When all platforms, particularly FreeBSD, have version 1.2 JDKs, it would be ok to code to that, but for now it doesn't really hurt to use the earlier version.
~Chris
I have yet to get 118 working on my BSD box. If you have a little free time, please mail me at kwerle@pobox.com. I'll describe my problems (mostly it involves a missing lib, I think).
Nothing is wrong with Make. ANT is just a cross platform 'Java aware' build solution. It functions much like Make does. Once again, I favor solutions that are Java based since that's where I'm concentrating my energies. (When you get old like me you have to focus!)
...Kevin
How about an ANT url?
How old is old? :-)
>How about an ANT url?
Dohl! Ok, here you go. http://jakarta.apache.org/ant/index.html
Ant is a part of the Jakarta Apache project. (Jakarta is the Java Servlet implementation that Apache and Sun are working on.) Which actually leads me into another option we could explore for the server side - Servlets. This is an area I've been actively pursuing at work.
>How old is old?
I'll turn 40, just after the turn of the next millenium.
Just to address a couple of your points...
Encryption was something I always thought would be a great thing. To allow encryption between EBJava and EBServ would mean that cleartext would not appear in your subnet where most sniffers would be waiting. I never got around to actually implementing any encryption, but the only real problem I think you would have is in the size of the applet... including some encryption libraries could be hefty and there isn't one that comes standard with the JDK.
For server side communications you might want to see if each socket is implemented in a seperate thread. I did a big threading overhaul that I don't think was ever complete, but it increased server speed significantly while lowering resources.
I also looked for existing libraries for communication, but didn't really find any for Java. There was one for Yahoo I found, but it wasn't documented that well so I whipped up the ICQ and TOC (AIM) clients you see there. One suggestion is that as of recently you can use TOC to get on to ICQ accounts, so I would suggest you replace my ICQ library with my TOC one.
I fully intended on moving the server to C someday, for reasons of performance, scalability, and the availability of libraries to access the services.
I also would discourage the use of Swing on the client. Yes, it would make a lot of things a lot easier and prettier, but it would require a whole lot of people to download the Java2 plugin, and in many situations that is not possible.
Guess that's it for now.
Chris
Chris,
>Encryption was something I always thought would be a great thing. To allow encryption between EBJava >and EBServ would mean that cleartext would not appear in your subnet where most sniffers would be >waiting. I never got around to actually implementing any encryption, but the only real problem I think you >would have is in the size of the applet... including some encryption libraries could be hefty and there isn't >one that comes standard with the JDK.
I'm not sure about the size of the applet if we add encryption. I'll check that out in a little test applet. It's been about 6 months since I worked with the encryption stuff. I don't recall what JDK it appeared in. Also, we could always deploy a base applet with add-on functionality to support additional features. That way only the users who want/need the add-ons will have to download them.
>For server side communications you might want to see if each socket is implemented in a seperate thread.
I'll check into this as I review the current code base. I don't intend on changing things much until we have the functionality and development direction down.
>I fully intended on moving the server to C someday, for reasons of performance, scalability, and the >availability of libraries to access the services.
I don't agree here. I think EBServ should stay in Java for platform portability reasons. If we stay in pure Java we stay portable; of course we can always use Java's ability to call into native libraries. I have some friends working on this.
>I also would discourage the use of Swing on the client. Yes, it would make a lot of things a lot easier and
>prettier, but it would require a whole lot of people to download the Java2 plugin, and in many situations >that is not possible.
Once again this is another trade-off. The plug-in is one way to attack the problem of not having support of Java 2 on a particular browser. Another option that I've been working with is Java Jump Start from Sun. This is a method of launching a full fledged application via a web browser. Kind of a hybrid between applets and applications. The good thing is once you load Jumpstart and get the application (or even applet) it gets cached on your machine and doens't require downloading again unless the application (or applet) has changed.
First things first though.
...Kevin