This file includes a summary of the things that need to be done in the near future, if you would like to work on something, please discuss it on the mailing list g-devel@lists.g-system.at. Look at the http://www.g-system.at homepage for registering for the mailing list. TO BE DONE FOR G SYSTEM DURING 0.5 RELEASE CYCLE: The 0.5.x release series focuses on the network layer. To actually start the 0.5 release series it is a requirement to be able to communicate between GWE Servers and to exchange data. It may crash, it may become inconsistent, it may be insecure... all this doesn't matter as long as it basically works. During the 0.5 release cycle we improve the network layer to make it as perfect as we can. The 0.5.0 release is reached, which is certainly one of the larger milestones in the whole history of the G System. Still, there are some improvements that need to be done during 0.5.x: BUGS * reparenting functionality is not complete, look at void GweController::handleReparenting() * 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). * MySQL (or the qt-mysql plugin) can't manage elementdata. look for MySQL todos in GStorage. * XMPP presence subscriptions are not working properly due to lack of XMPP server support (jabberd 1.4.3), look for HACKs in GXmppNetwork * Update Subscriptions are not yet in use. Look for HACKs in GXmlDataController and todos in GStorage DESIGN (desired for 0.5.2 or 0.5.3): * 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 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. * 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. * Persistent content Make persistent content possible. This includes: * Creating the required action widget (see client) to create elements. * 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. * GCS: influences It's possible that the current influence design is upside-down. Agents are expected to respond to influences. But actually influences should influence / act on target elements. Thus agents do not receive influences, but influences execute on the destination element ... or both ways? 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. CLIENT: * Make it possible to slow down rendering as desired (the msleep(x) variable between rendering updates). Create a slider for this. * Remove the "navigation instructions", they should be shown in a dialog box on startup with some additional information (like in gdemo). This text makes the screen a bit too cluttered (IMO, too much text) * Remove GForm dependency of the GCamera. Use the formChanged() signal from the user element to set the camera position. * Add information interface to display information about the element and/or the universe. Similar to the existing communication widget. * Add action interface to be able to perform actions with the currently attached element. Similar to the existing communication widget. PROTOCOL REQUIREMENTS: * Add version information in register message. * Handle presence stanzas, in particular also register (presence) to other clients so we receive presence stanzas. Then this info can be used to identify disconnected servers, ... Clients/Servers have two types of info: presence and registration, a GWE Server can be registered but offline!! * 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. JUNIOR JOBS (easy jobs that are suggested for getting started) These jobs are not necessarily fast todo, but should be doable without too deep knowledge of the system. If you want to work on one of these jobs, you can discuss this on the mailing list. * 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. general stuff, high priority: * 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. * Implement test cases for the whole API. A suggestion would be to look at the CPPUNIT test framework: http://sourceforge.net/projects/cppunit/ general stuff: * Most of the time there are things that need to be done, ask on the mailing list: g-devel@lists.g-system.at * Make progress towards the ultimate goal of the G System, look at HACKING and the docs in doc/gdocs documentation: * Always improve the docs, in particular the philocorner is of a high interest. It represents the thoughts behind the G System and G Universe. * Make documentation i18n capable. source code: * Make all strings i18n capable. * The network layer is now implemented, see GXmlNetwork and GXmppNetwork for details. The information below is kept for reference. What about grid systems? What about GLED? http://www.gled.org What about libMAGE? http://freshmeat.net/projects/libmage Other suggestions are welcome. This layer goes into the GWE library. 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. * 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. * Database layer needs to be done. This should probably go into the GWE library as well. See the GXmlStorage interface and the GXmlDataController classes. Consider using a relational model directly created from the element data and don't go through the XML layer. This would require an additional interface other than GXmlStorage. This would be the "ordinary" way to store things, discuss it on the mailinglist. * The client interface (GCE) needs much work... or basically it needs to be rewritten because the current implementation is mainly for testing purpose. * Network code for the client-server interface (build client directly on GWE?) * 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). OPEN ISSUES: Time/Space scaling, what about "fast" elements? (tunneling effect)