COBRA & OO Managers (Re: [Threedsia-dev] misc)

[Ilya K. <ri...@ya...>]

Hi List,

I exprience with a lot of aspects of OO and OO
managers two. COBRA is a nice thing cause it is
written and it is working without almost any big
problems and bugs! To move objects from one box to
another when those boxes has totally diffrent
arcitecture/OS/FS and so on, is very hard! The COBRA
description was developed mainly for this purpose and
it makes those things a "childs play". But to write a
COBRA (or anything similiar) implementation is *very*
hard because it deals with things *very* system
*dependebale*. 3Dsia can not reinvent all of software
to write its own code - if so lets create a new
programming language wonly for writing 3Dsia (it was
really done with XEmacs, it has its own lisp
implementation - XEmacs Lisp) or maybe lets design our
own architecture wich will work great with 3Dsia :-)
Try to look at the code of MICO (Mico Is COBRA) - it
is a big big big piece of complex software.    

--- xandi <xa...@bl...> wrote:
> hi all,
> 
> sorry for being so silent recently, haven't had
> enough energy to write..
> 
> ok, first of all, i have just commited some updates,
> as marc already said,
> which require some things to be done:
> get odb (cvs.odb.sourceforge.net, see gid 3089)
> use Makefile.lib.am to compile the library.
> (dont forget to make an automake after that)
> ./configure
> copy the lib into /usr/lib or whatever you use, copy
> all headers into
> /usr/include/odb 
> that should work; if you have troubles compiling the
> source (esp.
> frontend-plugins) then your egcs is too new, use
> -fpermissive
> (untested, should work though)
> 
> ok, those new sources are not at all beautiful;
> please forgive me ;)
> firstly the conversion from normal user-handling ->
> ODB only isn't
> completely finished (as the server does not read in
> the ODB, it just writes
> into it at the moment) but i guess i will do that
> today.
> secondly there are lots of old code fragments, not
> thread safe..
> thirdly the handling of incoming packets in the
> threads is not really beautiful.. 
> fourthly.. hm, actually thats what the TODO list is
> for.. 
> 
> TODO:
> server:
> 1) rewriting the buffers using STL and making them
> threadsafe and especially
> locking (at the moment all threads using buffers
> check in an infinite loop if
> new data came... thats a bit barbaric ;).  (a
> lock-attempt can be
> found in common/buffer.cpp, but my problem was that
> pthread_mutex_unlock crashes
> when the mutex is not locked.. why can't this damn
> thing ignore that?)
> 2) network-functions: a function that hacks big
> pieces of binary code into
> a number of MAXSIZE packets. (to transpher the ODB
> entries)
> 3) conversion from normal c/c++ to STL when useful
> (especially where pointers
> are still in use)
> 4) making various things in the current sources
> threadsafe (e.g. plugins)
> 5) making ODB a multithread application (please talk
> to manfred morgner about
> that) so that it can handle more than one request at
> a time...
> 6) intelligent buffer mechanism... (using
> timestamps, filtering,..)
> 7) putting all those packet-examining/forwarding
> things into nice functions (or
> into a class, as you wish)
> 8) improved plugin handling (talk to me about that,
> would take to long here)
> 9) a network frontend plugin + client (just very
> basic)
> 10) using the ODB->binary converter to send packets
> to the client and
> binary->ODB to add objects received from the client
> 11) messaging system so that clients can communicate
> with each other
> 
> client:
> 10) completing the conversion to multithreading
> 11) building the OglClib into the client
> 12) writing a keyboard-input-handler for the client
> (talk with marc, if
> its not marc who does it) - probably we'll use glut
> for a while..
> 13) haven't thought much about the new client yet...
> 
> external: (that depens on some tasks, so don't care
> about it now, i just want
> to say it:
> 14) an application that builds up a basic scenery
> which can be used for the
> first VR chat meeting. :)
> 
> i probably forgot some things, they will follow
> 
> ok, secondly, regarding the discussion:
> i do believe that all those things
> (RPC/Corba/XML/LDAP..) have their
> advantages, but they also have, of course,
> disadvantages.
> at the moment, i don't know enough about all those
> systems to say which one
> would be a real advantage for the project.
> Furthermore i believe that the best way to learn the
> advantages of a system is
> to know what it means not to use them. so there are
> two positive side-effects
> if we decide to write our own object manager: we
> probably learn some new
> coding techniques & we make mistakes (which is
> always a nice thing to learn)
> I believe, and please tell me if you think that i
> have gone completely nuts
> now, that this is one of the main advantages of the
> 3Dsia project; nobody
> here is a professional VR / distributed computing
> coder. We are unbiased,
> and can find new approaches to this topic; maybe we
> find a very good one,
> maybe the worst ever, maybe the best :D.. probably
> in the first steps one that
> is just "ok"; The next step is learning from other
> approaches, but i believe
> the first step has to be an unbiased one, in order
> to make lots of mistakes,
> and understand why those mistakes should be commited
> again..
> I have chosen the name "3Dsia project" because i
> think this is a project to
> create a really cool VR system. its not the program
> itself. so we can try lots
> of methods, maybe trying differnt designs in
> parallel. just to gather
> experience. we can experiment with all sorts of
> different things;
> we don't need to find the right approach from the
> beginning, i see it quite
> from the opposite perspective, i don't think it
> would be good at all to try to
> find it. but talking about those systems now is not
> bad anyway;
> gerald and marc and i see it the same way, we want
> to create one design-study
> (that is the sources we work on at the moment) and
> call it version 0.1, and
> version 0.2 will use more advanced methods, and
> might be a complete rewrite
> with completely new structures; and believe me,
> version 0.2 will be here quite
> fast..
> 
> ok, one last thing; i think i am not alone with this
> opinion, i think webbased
> discussion just sucks. but i have now problem to
> adapt if the majority of the
> mailinglist subscribers decides to use the webbased
> discussion.. but i don't
> like it, i have to say;
> anyway, i guess we should look out for alternative
> places, where webbased
> discussion _and_ mailinglist discussion at the same
> time is possible, so that
> the people who prefer webbased do webbased, and the
> people who.. yea.. :)
> 
> ok, thats for now
> bye
> Xandi
> -- 
> xa...@bl... - Vienna - Austria
> project: http://threedsia.sourceforge.net/
> personal:
> http://members.blackbox.net/alexander.feder
> 
> _______________________________________________
> Threedsia-dev mailing list
> Thr...@li...
>
http://lists.sourceforge.net/mailman/listinfo/threedsia-dev
> 

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com