RE: [Threedsia-dev] We're back again !

[Eric B. <eb...@us...>]

> From: thr...@li...
> [mailto:thr...@li...]On Behalf Of Marc
> Haisenko
> Sent: Thursday, March 23, 2000 4:22 PM
> To: thr...@li...
> Subject: RE: [Threedsia-dev] We're back again !
>
>
> > What exactly will the network activity requirments be?  It  seems to me
that
> > a lot of the interaction, for lack of a better description, is  very
similar
> > in concept to a web browser.
>
> Client and server have to 'syncronize' their SymbolTables, to say
> it in a quit short form ;-)
>
> > Maybe you could use basic TCP/IP.  Or maybe Corba if your looking for
object
> > oriented interaction.
>
> Basic TCP/IP would force us to support TCP/IP only... I don't think that
this
> would be a good idea, as 3Dsia has to work when TCP/IP's gone...with no
major
> code-rewriting...

And how does this differ from using RPCs?  In TCP/IP world, there is a thing
call the loopback which is intended for use with local and non-network
oriented packets.  And if you are doing network traffic..use network
traffic...if you are not on a network...where does the network traffic enter
into the picture?  Are you visuallizing locally and if you need to connect
to another machine then you make a network call...if the network call is
unsuccessful, then (if good error checking is include) it will catch it and
either complain or perhaps you could indicate (take a reference from
Lawnmower man here) that the connection/port/portal/door is locked.

> and calling CORBA a monster would be ridiculous, as it is
> much more than that: it's HUGE, it eats ressources, etc. I don't
> think it would fit our needs

I must admit...I haven't programmed with Corba much, so you could be dead on
on this one.  But remember what it offers (AFAIK).  It offers Object Request
Brokering (as the name implies).  This means...if you have a virtual object,
that needs to interact with anothe virtual object (locally or via the
network), the ORB handles all the interaction without you having to screw
with all the network concerns.  The Gnome guys use it (or their version of
it) all the time (check http://www.gnome.org for additional links in the
development side).  Perhaps we could use one of the versions and only use
the features we need...cutting out all the extra fat...although there are a
lot of people working on CORBA..so there are probably reasons for why they
did a lot of what they did.

> > If you are going to do network activity...you will have to have a
> > client/server aspect no matter what, even if it is included as part of
the
> > client (start the client application and it starts waiting for requests
from
> > other clients).
>
> Nope... clients are connected through a server... they may connect
directly if
> they know each other, but initial client->client communication goes
through the
> server. And the server only responds to requests from the client.

Let me expand on my statement a little bit.  Let's use as an example, IRC.
With an IRC client, you have to connect to an IRC server.  Connecting
requires that you send a request to the IRC server for a connection, the
server receives the request, processes the request, sends a response to the
client, who is waiting for a response, the client receives the response,
displays the output, and waits for the user to send another request or
display additional responses received from the server (like new messages or
lists of channels,etc).  It constantly waits for response from the server so
that it can display then response.  In this way, the client acts like a
server in that it is waiting for the server to request that the client
update its output with the corresponding feedback the server has provided.

> > > > This leads me to a very important thing: WE DO NEED PROGRAMMERS
> > >
> > > Here I am! Tell me what to do! ;-)
> >
> > Ditto...
> >
> > I haven't looked that far into this...what platform are you
> planning this
> > for?  Are you g++? Visual C++, etc?  WIll you be using
> > Opengl/Mesa/DirectX/etc?  Will you be using something like QT or GTK++?
>
> Register yourself at SourceForge (www.sourceforge.com) and tell me your
account
> name, so I can add you to the list of developers. This gives you complete
> access to our CVS, where the code is. Currently we are only Linux, but
plan to
> support several plattforms (with one restriction: the won't be any
Win95/98
> servers, or at least we have not planed any because of it's
unstable/unsecure nature).

I am known as ebresie on sourceforge.net

> We are using g++, but any C++ should do (if not, please fix or tell us
where problems are).
> We will use OpenGL. That's normally Mesa under Linux, but any
> OpenGL should do (but no 'MiniGL')

> Qt is used at the moment in a server-frontend (but the whole
front-end-thing
> will be extended) and at client side for initial client-configuration...
GTK++
> may be used as well, just write a plug-in (see the source)... the actual
client
> is not using any GUI-toolkits (why should it ?)
> Oh, btw: and welcome to the team ;-)

I think either one or the other...but QT and GTK more or less offer the same
functionality...you would just be making it more KDE or Gnome user friendly.
Different APIs for the same thing.

Eric Bresie
eb...@us...