ebjava-devel Mailing List for Everybuddy Java

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

You seem to be on good terms with the everybuddy.com folks?  Perhaps we
could move the project into the com.everybuddy... domain?

Kurt
-- 
---
kw...@po...
http://www.pobox.com/~kwerle/

> Maybe not, we'll see. I just want to keep code for, for example,
> downloading files out of the applet's jar file.

Why?

> > And while I'm on the subject, all the classes should really be
> > put in a package, but I note you don't have your own domain (and mine
> > isn't much of one :-)
> 
> :) I didn't know anyone actually did that. I knew Sun had intended it to
> be that way, but does anyone really ever do it? I've seen it happen
> about twice.

Um...  Everyone does!  This is the first code I've seen that is not
packaged.

> > The only crazy thing I'm considering doing is writing a text-only
> > client.  Just so you know I don't plan on doing anything too extravogant
> > with the code base...
> 
> [stuff about non-java comms]

No, I meant text only java client :-)

> Also, I'm trying to get a perminate site set up to host EB. I guy
> offered, and I even made preconfigured tarballs for him, but he seems to
> be the type that needs to be prodded every step of the way. It's
> frustrating.

I'd offer, but my server is a lowly 486 running out of RAM and HD
space.  It certainly does not run Java.  I just purchased a new HD for
another potential server box, but it spontaneously reboots during some
disk activity.  Bad mobo?  Anyway, no can do...

Kurt
-- 
---
kw...@po...
http://www.pobox.com/~kwerle/

Kurt Werle wrote:
> 
> Not that I'm complaining, but isn't there a dev list that we could use
> for this kind of discussion?  Then our thoughts would be recorded for
> posterity sake, I think (or is that a good thing?)...

Yeah, I checked and saw that you were subscribed for digest, and I
wanted to get ahold of you quickly without waiting for the digest to go
out, so I went ahead and mailed you directly :) Perhaps I'll send these
messages the the mailing list later. Probably not.

> The best reason not to that I can think of is that we don't need to.  I
> don't plan on doing anything with this that would force a branch (more
> than I've done already, anyway).

Well, for instance the setup now has the app class being put into the
jar file with the rest of it.
I realise a tweaking of the make file could have the applet go in one
output directory and the application in another or just not include the
EBApp class in the jarball or whatever, but it still seems like since
the application can have more and different functionality, that it
should be moved off to grow on its own.

Maybe not, we'll see. I just want to keep code for, for example,
downloading files out of the applet's jar file.

> The "Right" thing to do would be to write 2 libraries and 2 clients.
> The libraries would be the client&server shared code (dunno if there
> is/will be any) and the client only code (common to all clients).  The
> server would use the former library and the clients would use the
> latter.  

There is a very small amount of shared code at the moment... like code
that converts integers to arrays of bytes and back for ICQ. I don't
forsee all that much sharing of code there, really. Now sharing code
between clients would be something completely different. 

> And while I'm on the subject, all the classes should really be
> put in a package, but I note you don't have your own domain (and mine
> isn't much of one :-)

:) I didn't know anyone actually did that. I knew Sun had intended it to
be that way, but does anyone really ever do it? I've seen it happen
about twice.

> The only crazy thing I'm considering doing is writing a text-only
> client.  Just so you know I don't plan on doing anything too extravogant
> with the code base...

Yes, I had always wanted a text only version like AOL's tac, which I've
found very useful over the years. 
With regards to clients I have to point out one feature that I built
into the server. When the client is contacting the server, the first
messages are just \r\n terminated strings until the client sends the
string EBBIN\r\n. After that, they communicate with Java's built in
methods to send and receive various datatypes, for instance sendUTF() or
sendBoolean(). From what I understand, these are special in that they
can't really be read by programs written in other languages without
going through some hoops, but they make it really easy and efficient to
write communications code in Java. 

The point is that I intended that if the client sent something other
than EBBIN it would use a different mode of communication (which are not
determined or implimented because oflack of need at this time). So you
could write a C client that would use \n\r terminated strings to do
everything or whatever you wanted.

I don't know if this would be useful to you for this, but I'm going to
CC this to the mailing list after all, s I thought I'd mention it.

> While we're chatting...  My IDE of choice these days is JBuilder
> Foundation (the free (as in beer) version).  Should I include the .jpr
> (project file) in the cvs repository?  It ends up being clutter for
> anyone who doesn't use it, but if folks use it then it's good to have
> there...

Yeah, I noticed the file. I really have no clue if it belongs in
there... I don't even know if those images belong in a CVS, but some
people asked for them. I guess I'd say leave it in until someone
complains :)

I think that's I wanted to say for now. The area that needs the most
work is ICQ. I'm not even sure what the status of it is because there's
a killer firewall around my campus here, so I can't test it. I have been
told that it can send messages through the server, though, and that you
can see someone signed on to ICQ through EB.

Also, I'm trying to get a perminate site set up to host EB. I guy
offered, and I even made preconfigured tarballs for him, but he seems to
be the type that needs to be prodded every step of the way. It's
frustrating.

~Chris