[crossfire] jcrossclient lives.

[Brendan Lally]

On 11/11/05, Yann Chachkoff <
     yann.chachkoff at myrealbox.com
     > wrote:
>
      Just a small question: Why hasn't been jcrossclient made part of the Crossfire
     >
      project, but is being maintained separately ? It seems a bit strange to me,
     >
      especially since there is obviously no licencing issue.
     
There is also no code shared between the two.

Whereas the cfclient/gcfclient/scfclient and gcfclient2 are all
written in C, using the same code in common/ jcrossclient doesn't.
Everything is written in java (or with the newer parts in a mutated
form of java that is pretending to be C, but that is more an issue of
my coding style).

Also the eventual goal is different. I intend to modernise the
featureset of jcrossclient, to match up to current servers, but after
that, I intend to turn it into a web applet, so that crossfire servers
can offer a way to play on them with a web browser using a java plugin
(mikee has already told me that he will do this with cat2, once it is
working)

This is still a couple of months away, but even so, it is the nature
of such a goal that the release schedule will be different for
jcrossclient compared to crossfire as a whole (and, at least
initially, I expect be having a release every week or two as I try to
stabalise towards a 1.0 release. - having these releases announced in
connection with the main crossfire project may very easily cause
confusion, especially since the version numbering is different (look
at the number of questions that occured around the time of the 1.7.1
cfclient/gcfclient release).

One final point, the controls are subtly different, and the nature of
awt is such that it would be very hard to get it to mimic the gtk
clients behaviour in all respects, as such it is likely that there
will need to remain seperate control documentation, which again is
harder to differentiate in a single project.

Do not think however that this means that there will not be
significant design and code overlaps, I have already ported/mutilated
some code from gcfclient for the map1a parser, I would like to think
that in future such a transfer could also happen the other way,
although that is not likely to be until there is more code to borrow.