[Balder-devel] Fwd: Anything happening ?

[Bjorn H. <bh...@uv...>]

I haven't had time to digest and understand this yet, but I'm back home now 
so I should have things (my life) under control in the next weeke here 
sometime : P
I really should have passed this along earlier:

>Hello all,
>
>(Can't send do balder developpement list)
>
>As nothing is happening, here are a reply to a mail I sent earlier
>regarding a proposal to get something of a CEL look-a-like with possibly
>some tweakings for network.
>
>    The base concept is that a iMetaClass exists and actuall implementations
>are accessed via a plugin technic. iMetaClass builds up iClass's. iClass's 
>are a collection
>of slots and methods. iClasses creates instances. Nothing of an iInstance is
>accessible without a call through the 'callMethod' or the 'get/set Property'
>of the iClass method.
>
>To summerise:
>iDb
>    has a way to access all instances through Id.
>    has a way to load up iMetaClass
>    has a way to access all available iClass
>
>iMetaClass
>    -> builds iClass
>        iClass
>        has Slots holding properties
>        has Methods
>            ->builds iInstances
>               iInstance
>                    has an idea
>                    has some storage for the slots/Methodf (if the method is
>                    a script for instance)
>
>    What do we get with that ?
>- lets consider we have a network update frequency of 20/seconds (so,
>we have a packet leaving every 1/20 th of a second), the iClass 
>'get/set/callMethod'
>can log all relevent changes into a buffer, and when the train has to leave it
>is sent out. All 'slaves' at the destination(s) gets the get/set/calls in 
>the same order
>of creation. Method calls are like kind of events, set (we don't care 
>about get) are
>like 'streaming' update. Instance creation is a callMethod, therefore it will
>go through network also. For slots, we might consider first than only the last
>'set' get sent away (interpolation technics are used to ensure that not to 
>high
>jerkiness arrise because of this).
>
>- Instance creation is also a special call, therefore, on the client where the
>    call method is made, the instance is defined has being a 'master'. On 
> all the
>    other sites, 'slaves' instances are created. Master/slave means that 
> all slots
>    are read-only in the slave. But method calls are still possible on the 
> slave
>    instance.
>
>    I am currently writing up a first implementation of the meta class 
> stuff. If anybody thincks
>of reasonable improvements, I am all hears. The goal is to avoid having 
>the following kind
>of code:
>    if ( isNetworkEvent ) {
>        ....
>    } else {
>        ....
>    }
>    Spread out al-over the code. Note also that 'slots" can be simulated. 
> Lets say I have
>a normal C++ class with some attributes, then we can arrange for the 
>iClass created by the
>iMetaClass to 'virtual slots' (that dont'really exists) to access the 
>native attribute.
>
>    The network 'train' concept is 'hard'. That is we send data every 1/20 
> th of a second
>whatever. So, if the data gets to large that it would impair the ability 
>to send 1/20 of a second,
>then we send right away and start filling up the packet for the next 
>train. This would raise
>some flag if we can do something in the game to reduce network traffic. 
>Otherwise, we
>are in trouble and can't do anything about it !
>
>    Best regards,
>
>            Sebastien.
>
>PS: I have a build method for MSVC Win32, but has the source tree is still 
>probably going to change in the
>futur (we have plugins in what I describes here), I am keeping it under 
>the hood for the moment.



>By the way my idea on creating a meta data model is exactly
>the ground basis for VOS (http://interreality.org/). But might be slightly 
>overkill in term of being too
>generic. Also if licensing allows, we could start with this and eventually 
>tune it for our purpose.