BUGS

• There have been some quirks with jabberd 1.4.4 servers which (wrongly) advocate XMPP 1.0 compliance. This should be handled in GXmppNetwork (if at all). This will be fixed in one of two ways: with moving to the current Qt4 based libiris version or using fully compliant jabber servers, like ejabberd. Please note that by now the Qt4 based iris library is not yet available, thus XMPP is disabled by default in the G System.

• MySQL (or the qt-mysql plugin) can't manage elementdata. look for MySQL todos in GStorage. DO NOT USE MYSQL DATABASES FOR ANY GUNIVERSE SERVER DEALING WITH PERSISTENT DATA (not yet relevant since nothing is yet persistently stored accross restarts).

• XMPP presence subscriptions are not working properly due to lack of XMPP server support (jabberd 1.4.3), look for HACKs in GXmppNetwork. Again, move to ejabberd, or similar XMPP compliant servers.

• Update Subscriptions are not yet in use. Look for HACKs in GXmlDataController and todos in GStorage.

DESIGN

• Add a signal for connection changed in the element and use it in the GElementInfoWidget of the client.

• Proper load management

  • Introduce sorted LastUpdated list in GWE in order to close elements that do not show activity for a long time

  • Additionally provide a void mayPark(); method in GCS::GElement and GCS::GAgent that checks all agents whether the element may be closed. In GCS::GAgent this should simply default to true.

    Be careful, this might be a bad idea as from time to time elements simply must be closed for example when the application itself closes. But the LastUpdated list is a good idea.

    Improvement: do implement this mayPark infrastructure - to use it when going through the last updated list and looking for elements to be closed. Simply close those that return true. In situations where elements must be closed don't evaluate mayPark but simply do it.

• Jabber Servers with pre XMPP 1.0 protocol do not handle presence subscriptions. We should definitely *just* allow XMPP 1.0, also put up a server that clients can use as Jabber Server (universe.g-system.at). Currently it works with both :) but we should limit to XMPP 1.0 in due time.

• User elements:

  Getting an user element for a client should not be the responsibility of the client but rather that of the server to provide a pool of available elements that can be requested/created by a new client. Technically this would mean to transport element responsibility (see protocol requirements). Once an user has chosen an element this information is kept since unregistering and presence are two distinct things (see protocol requirements). As soon as the user is present again, that very element is transported to the user again. It should also be possible for the user to query for those elements that belong to the user (again, see protocol requirements).

  I would suggest to implement this in 0.6, the G Universe client should start out without any client and be able to select one from the given world (raphael).

• Universe creation and initialization: Currently the server creates one big big universe object on startup. This needs to change since with a DBMS backend we get persistent storage at no cost. Then injecting the first element should also not be the responsibility of the server application but rather that of an administration tool like GOD. GOD should connect to the server through XMPP (needed at some point anyway) and be able to inject elements as well as fetch information about elements. Please note that with the dawning of the G Web-Interface such administrative things can also be done through the GWI.

• Make persistent content possible. This includes:

  • Improve the protocol to run from existing database content (utilize the gweserver hierarchy, last column of the gweserver DB table)

  • Improve the client to fetch its element from the server.

  • Possibly improve the client to create its persistent client element.

• Forward changed signals also to the agents of the element. Probably provide predefined slots that can be reimplemented if desired. Connect these slots in GCS::GElement::addAgent()

GENERAL

• TEST THE NETWORK!

• Installer improvements: automatically check for patches in patches subdirectory and apply them before compiling - user doesn't need to know how to handle patches. This is generally postponed to the 0.7 release.

CLIENT

• Make it possible to slow down rendering as desired (the msleep(x) variable between rendering updates). Create a slider for this.

• Add global information interface It should show things like current parent - like in which solar system the user is in and maybe server status, whatever. Element independent information. This should be placed at the top (a long, thin widget).

• Add element information interface to display information about the element and/or the universe. Similar to the existing communication widget. This should be placed at the left border.

  Information should include:

  • Current size

  • Energy

PROTOCOL REQUIREMENTS:

• Move element responsibility (this is certainly a non-trivial thing to do really right, but basic support for it should be done already). This is required to be able to select a client element from a pool of existing elements.

  This can be done with the "owner" attribute of a GElement message. The original owner sends the element with the updated owner attribute to the new owner who recognizes that the incoming element needs to be taken over. There should be a confirmation message that the element has been accepted or denied and a timeout which defaults to denied (don't lose data!).

  Different approach: subscriptions need to be transported as well. Thus I would suggest sth like:

  
    <moveelement>
      <GElement/>
      <subscriptiondata/>
    </moveelement>
    The receiving server should send some kind of acknowledge message, like:
    <elementtaken id="523"/>
  

  id should be the element id that has been moved from one server to the other.

  Likewise there can be a <elementrejected id="523"/>

  See GXmlDataController::receiveData() for protocol stuff!

• The user should be able to query for elements belonging to the user (see design todos)

• Write a coding style guide based on the G Core System (src/core). Coordinate this with the mailing list. Doing this would be appreciated and should be done before anything else as it helps newbies to write clean code.

• Add a tutorial for advanced agent creation

  This tutorial should probably create a solar system with agents orbiting the center - a GOrbitingAgent, this would also be required to create planets in a solar system. See below for todos in the documentation. This tutorial should go into the chapter on using the G System.

• Implement test cases for the whole API. Qt 4 includes an unit testing framework.

• Also update the iris XMPP library when porting to Qt4. The new iris library was already in src/worldengine/iris but it is not yet functional with Qt4 (does not even compile, thus removed). Look at http://delta/affinix.com/iris/ for details. It would be useful to investigate the current state of iris (contact the PSI developers!) and see if it can be reintegrated into the G System, maybe as an external library similar to the X3DToolKit.

• Most of the time there are things that need to be done, ask on the g-devel mailing list.

• Make progress towards the ultimate goal of the G Universe, look at HACKING and the docs in doc/gdocs. We've also written a vision paper in October 2006 which gives an outline on the vision of the G Universe. It is currently not included in the G System documentation, but might end up in the philocorner. For now, contact Raphael to get a copy.

• Always improve the docs, in particular the philocorner is of high interest. It represents the thoughts behind the G System and the G Universe.

• Make documentation i18n capable.

• Provide much more documentation for the users of the G System framework (they are developers). See the chapter on using the G System. The tutorial needs the be replaced by a newer version, it is very misleading by now (originally written for the 0.3 version of the G System).

• Make all strings i18n capable. Use the Qt translation infrastructure for this, which basically means to use the void tr(); method. This is already done to a large extend, look through the application and complete this task.

• The network layer is now implemented, see GXmlNetwork and GXmppNetwork and GXmlDirectNetwork for details. The information below is kept for reference.

  This layer goes into the GWE library.

  Possible implementations:

  • What about grid systems?

  • What about GLED?

  • What about libMAGE?

  • Other suggestions are welcome.

  • Latest suggestion: Jabber, it also makes it potentially possible to take primitive actions from ANY(?) Jabber client. Also Jabber is a distributed network(!). This solution is currently the preferred one.

  • One more latest suggestion: GLOBUS, a grid system. This means that all network related components should be implemented as grid services, take a look at GLOBUS related papers, they include pretty much information about grid architecture.

  • With regards to changes in element data (GCS::GElementData): only send partial data of elementdata (that is, if /dynamics changed, only send /dynamics, not the whole elementdata... saves bandwidth).

• Refactor GWE::GXmlDataController::receiveData

  Each message should be interpreted by a separate message interpreter object. Such objects can be added to the data controller externally. Interpreter classes should implement a specified interface by the GXmlDataController class. The objects can be stored in a map where the key is the actual message tag the object can interpret.

  Maybe use threads for message interpreters to not block the network for too long. Be careful here though. In particular you should import the QDomNodes that were received in the message to a separate document before forwarding it to the interpreter as a thread.

• Use multithreading for GWE more extensively to not block too long. This can now be done, the G System is ported to Qt4.

• Now that we use Qt4, the Agent plugin infrastructure can be put in place by using Qt Low-Level Plugins - http://doc.trolltech.com/4.1/plugins-howto.html

  This also works with C++ agents, not just interpreted (scripted) agents.

  This basically affects the GWE.

• Network code for the client-server interface (build client directly on GWE like it is done now?)

• Have a look at the todo list of the API Reference for more things.

• You'll also find lots of @todo items in the sourcecode itself (grep for it).

• Investigate possibilities for using mathematical expressions for element geometry

  • This would make LOD (level of detail) easier as well.

  • The muParser might be useful for this purpose.

  • This is mainly a rendering plugin for the GCE, the agents just need to put the desired expressions into the element data.

• Time/Space scaling, what about "fast" elements? (tunneling effect)

• Collision detection and response Difficult if every element has to implement it itself, though this would be natural. A different approach would be to give the parent element better control over its children, but this is unnatural. There is a thread in raphael's blog about a suggestion. This suggestion is generally a bad idea.

• Energy level and sigma - all elements that somehow relate to each other must share the same energy level range in order to be able to respond to influences that affect physical matter as such.

• Time synchronization between servers, especially important to add a timestamp on influences, etc. so the receiver exactly knows when an influence was sent. Note: if the receiver looks up data from the sender the fetched data might be of a different time point than when the influence was sent (different time-difference).

• Events and listeners between elements (formChanged(), energyChanged(),...). Does this comply with the influence mechanism? Especially if elements don't have the same parent (influences usually don't go through that).