Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: From c to c++ (or even java)
- To: crossfire (at) ifi.uio.no
- Subject: Re: From c to c++ (or even java)
- From: Petri Heinila <>
- Date: Thu, 7 Dec 1995 16:50:57 +0200 (EET)
- In-Reply-To: <>
On Wed, 6 Dec 1995, Mark Wedel wrote:
> It would seem to me that you would almost always want the server side code in
> C or C++ or something like that - I don't know much about Java, but crossfire
> seems to be a bit huge to sit as a java app.
>
> What would perhaps be more interesting is to make a java client that somehow
> interacts with the server. This opens up crossfire to everyone, removes the
> difficulty of having to port clients to every different system type, and does
> achive the long sought after client/server aspect.
some points:
* crossfire requires peer-to-peer communication with client-
server architecture (peer-to-peer means there is spontaneous
data exchange for both direction (server sends maps, client
send commands) not request-reply, client-server means
instantiation roles, server up first, client then with
known server address).
* in java architecture program (applet) is created and precompiled
to bytecode in provider site. www browser the makes a request
for that program, that is then replyed to the browser. browser
starts plugin java-interpreter that runs byte-code, resulting
ususally graphical presentation to browser.
* for crossfire I see there is possible to make java-client,
that when it's runned makes a connection to cf-server by
java-network-objects (does this exists ?)
* for creating server by java is a bit problematic thing
with java architecture. It might not be reasonable to run
cf-server on www-browser with java-interpreter (does
there exist stand-alone java interpreters ?).
more later ;)
<A HREF="http://www.lut.fi/~hevi/"></A>