Hi, My name is Sergiy and I am working together with Torsten on FiVES. You are right that FIVES is similar to realXtend. I have been one of the core designers of FiVES and borrowed some of your ideas. However, there are key differences as well. One important difference is the plugin-based design, which allows us to easily reconfigure the server to the requirements of a specific application. The core of the FiVES is designed to be very small and should only contain functionality applicable to a very wide range of applications. In our design core contains functionality to access in-memory ECA model of the world, a set of methods for plugin management and KIARA. The rest is provided by the plugins (see below). In FiVES, KIARA plays a similar role to kNet in realXtend, however, it is also different in many aspects. Unlike kNet, programmers are not required to write serialization code (e.g. like this one<http://clb.demon.fi/knet/_immediate_mode_serialization.html#UsingDataSerializer>). This code is generated at run-time by analyzing the user types with reflection. It automatically converts application-specific types to the protocol representation and back, allowing to write clear code not polluted with middleware objects. In addition it is designed in a way that allows to add or change protocols at run-time time based on current needs (security, efficiency, QoS etc), which makes the system very flexible and doesn't require recompiling or restarting the application each time. There is even a planned support for high-speed RDMA connections which would be very useful for inter-server communications. I should admit that many of these features are not present in our prototype as full version of KIARA is developed independent group in FI-WARE. In our application prototype we use a simple JSON-based protocol over a WebSocket connection as proof-of-concept. In addition we use KIARA as an inter-plugin communication system, where no serialization overhead is present and data structures are passed directly between functions. Plugins use KIARA to provide interfaces of their own. This allows them to function as building blocks. For example, if one builds a Scripting plugin it can be used to provide additional functionality in ClientSync plugin, which may use JavaScript boolean expressions to determine whether a certain attribute is to be synchronized or not. Another example is Auth plugin. It clearly separates authentication and authorization matters, yet it provides all other plugins with a way to determine whether a certain use has necessary permissions. As already mentioned by Torsten, plugins can register components. This is done on purpose to establish a clear link between the functionality and the component. For those components that are used by several plugins, we create simple plugins, such as "Location", that only register the component and make other plugins depend on it via a static dependency declaration. Apart from static dependencies, plugins can also have dynamic dependencies. For example, Editing plugin provides an interface for clients to create new entities, but does so only if the ClientSync plugin is loaded. It will not fail to provide other interfaces to other plugins if this is not the case. Hope this helps, Sergiy Sergiy Byelozyorov Computer Graphics Chair Universität des Saarlandes Tel.: +49 (681) 302-3833 http://graphics.cs.uni-saarland.de/sergiyb/ On Tue, Sep 24, 2013 at 9:45 AM, Toni Alatalo <toni at playsign.net> wrote: > Just a quick note: thanks for the clarifications, I think it's all pretty > clear for us from this now. > > Is similar to what we have within realXtend, where kNet is like KIARA and > Tundra is like Fives, and the avatar example app built with Tundra again > similar to your example app with AVs (the Tundra example / reference av app > is https://github.com/realXtend/naali/tree/tundra2/bin/scenes/Avatar) > > So how will this be licensed once you publish it? And is the idea that > this is somehow connected with other efforts in WP13 or a separate > individual effort whereas the other parts in MIWI use networking from the > Synchronization EPIC & the existing Tundra server? > ** > ** > On Sep 24, 2013, at 10:09 AM, Torsten Spieldenner < > torsten.spieldenner at dfki.de> wrote: > > Hello, > > thank you for your thorough feedback! > The code is not open source, but we plan to publish it for you to have a > detailed look once we reached a stable version of the current > functionality. We want to have this ready before Friday, there are still > some parts under testing, but we think that the remaining issues should be > solved soon. > > I noticed that I did cause some confusion concerning KIARA, FiVES and the > actually documented application. > > KIARA is no application, but the communication middleware that is also > part of FI Ware / WP 13. It hides actual protocols from the user by > providing wrapper functions like those I've put into the documentation. All > details about connection, serialization etc. are no longer to be taken care > of by! the deve mitted using KIARA can be provided using data structures > like the Vector or Quat structure I've introduced in the documentation as > well. Internal data structures of specific applications can be mapped to > those KIARA data structures by providing respective mappings in an IDL > file. KIARA then takes care of correctly serializing, transmitting and > deserializing the data. > > > FiVES is the application layer that provides the mechanisms to create > Virtual World applications by putting together sets of plugins. If you > start the server a second time with a different set of plugins than the > first time, it will only use the data provided by the plugins at second > start. So, in general, FiVES is actually not meant to be the basis for only > a certain kind of application, but rather to provide a way to come up with > any kind of synchronised world by creating and selecting a respective set > of plugins. > > The documentation so far is a documentation of Plugins we have written for > a specif! ic exampl be a Virtual World Client with scriptable 3D objects > and users represented as animated avatars. This is also the reason why > "Avatar" depends on "Renderable" currently: In our case, an avatar is the > 3D representation of a user in the world. As 3D renderable objects are > already introduced by the Renderable plugin, we decided to use > functionality introduced by this plugin and made avatar depend on that, > rather then re-implementing what Renderable already does. If you like to > run the world without having visible users (like the SimCity scenario you > mentioned), all you have to do is to start FiVES without the avatar plugin. > Users will then not be represented in the world. > > The actual login information (like session tokens) is not managed by > avatar, but by an Authentication plugin. Both Avatar and Authentication are > currently still under testing, and the way how 3D entities representing > users are connected to a specific user account is likely to change. > > Concerning and p! osition, sumption concerning default values. Those can > either be specified when defining the Component Layout, or they are just > set to a "default default" value by FiVES (if not specified by the plugin). > > Separating scale from position and oriention was a decision we made, as we > may have positionable objects without any visual appearance, so we saw no > need for scaling those. The resulting over all transformation could of > course also be managed via a transformation matrix. > > Concerning the Editing Plugin, you are right. We don't support adding > non-visible objects to the world yet. > > Again, thanks a lot for the feedback. I will revise the documentation > (and make the differentiation between the different parts of the > application clearer as well) as soon as the we proceeded with testing and > the interfaces are less likely to change to anymore. > > ~ Torsten > > > Am 9/23/2013 3:20 PM, schrieb Toni Alatalo: > > Thanks, we checked this quickl! y with Er estions: > > > First, is the server implementation open source and, if yes, where is it? > > Then some points about the entity model and VW functionality: > > You have apparently kind of hardcoded the concept of the avatar, tied > login information so some 3d positioned entity etc. This is something that > we were very happy to *remove* in realXtend when switched away from LLUDP > and Opensimulator. In Tundra the client connection information is in the > UserConnection object and it's up for the application logic to decide > whether and how user presences show in the ui / scene. I think we want to > keep that. For example in a SimCity like scenario the users don't > necessarily have any 3d presence at all even though they are all > collaborating in the same 3d scene. Also when making e.g. a chat + > whiteboard application without a 3d scene it's weird that the platform > would insist putting some 3d position for the presences. Of course if the > scope of FiVES is only for certain kind of a! pplicatio c platform like > with Tundra, this can make sense (I don't really know what FiVES is, only > a glance from quick search). This is sup > > po > > sing that the Avatar plugin in your doc is considered a 'core plugin', > and it would seem so as ClientManager depends on it. > > Likewise in the messaging there are avatar specific messages etc. There > we've resorted to generic attribute manipulation and entity-action > triggering calls, not having application specific things in the platform. > Perhaps I am reading this the wrong way -- KIARA being the generic > application agnostic layer, whereas Fives is like one application (some > system with avatars)? This probably also shows how we don't know what your > effort is and how it is perhaps related to FI-WARE.. > > Also, we were curious about the rationale for separating the scenenode > matrix to position, orientation and scale components. I'm not really > criticizing that (yet :) but trying! to under gle 4x4 matrix in the end > anyways so has seemed straightforward to handle as such in many places -- > though in networking it is often handled with more granularity, perhaps net > message optimisation is your motivation as well? Anyhow it seems a bit > strange at first in the entity model that something could have an > orientation without a position, or a position without scale .. I suppose > then you'd default to 0 position and 1 scale etc? What happens for a piece > of code that encounters a positioned object and tries to read it's scale - > it gets the default value if the scale component doesn't exist? Or no value > is returned, as the component doesn't exist? But the rendering uses the > default value of 1 so it looks like the component existed? That would be > confusing I think. > > For editing I'm not sure if the 'Location, Renderable' dependencies are > necessarily - in Tundra we are used to having non-position so-called > application entities which only have a script component. We can e! dit > those d parameters) over the wire without those entities being placable nor > renderable. Your script component seems similar to realXtend's so perhaps > the same logic for editing would apply, or do you mean something else with > it? > > > Cheers and thanks for sharing, > ~Toni > > On Sep 23, 2013, at 3:44 PM, Torsten Spieldenner < > torsten.spieldenner at dfki.de> wrote: > > Hello, > > a first, very high level overview of FiVES Entity-Component-Model, list of > Components, Plugins and the KIARA Interface for > Server-Client-Synchronization are now available at > > > https://forge.fi-ware.eu/plugins/mediawiki/wiki/miwi/index.php/Current_FiVES_implementation_details > > Please note that the interface is still under design, and there will be > slight changes to the existing Plugins / synchronisa! tion func ery likely > to come during the next days. > > The client will then support rendering of entities by referenced XML3D > mesh resources, as well as users that are represented as avatars, including > a very basic user authentication. > > ~ Torsten > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > > > > _______________________________________________ > Fiware-miwi mailing list > Fiware-miwi at lists.fi-ware.eu > https://lists.fi-ware.eu/listinfo/fiware-miwi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130925/79b2ce50/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy