Open Kite Project Toolkit

High Level Requirements [1]

• The toolkit should be general-purpose. It should be able to deal with the design of all types of kite, not just soft foils. Specialisation for a specific kite type will occur at the user interface. It should be possible to have two radically different user interfaces (i.e one for developing windsocks and another for developing trick kites) which use exactly the same core engine.
• The toolkit should be able to run on any modern computing platform - specifically any platform with a reasonably complienat C++ compiler and a decent implementation of the STL.
• The toolkit shall use as much predeveloped code as possible - Let's not reinvent the wheel. [3]
• The toolkit will be designed an built in a 'component' fashion - each component will do one job, and do it well.
• If possible, these components will be able to be included / excluded at run time. (This is definitely a 'nice to have', but let's try to keep the design clean enough that we can add it at a later time)
• These components will be totally cross-platform - It should be possible to build them on any supported platform and guarantee that their output will be identical across those platforms.
• (G)UI components (the 'front end') may be platform-specific, but no one platform should have features not available on other platforms unless there are very good reasons for it.
• The back end storage system may also be platform specific, but should provide exactly the same functions as every other back end storage system. i.e. all components should be able to make the same assumptions about the storage system.
• The toolkit should be distributable - i.e. central server(s) being accessed by remote client(s) across a network, but the design should not preclude a 'monolithic' build a la 'Foilmaker'.
• It should be possible to build a 'stand-alone' version of any of the components in order to carry out a specific task. [2]
• The toolkit should be able to deal with multiple people working on one design.
• The toolkit must be able to deal with importing and exporting files in the proposed cross platform exchange format.

Architecture (High Level)

      ________
     /        \
    +          +
    |\________/|                +----------+                  +-----------+
    |          |                | Database |                  | Component |
    | Database |<-------------->|  Server  |                  |  Manager  |
    |          |                |          |                  |           |
    +          +                +----------+                  +-----------+
     \________/                   ^                            ^ |  ^
                                  |                            | |  |
                                  |   +---------replies--------+ |  |
                                  |   |  +------requests---------+  |
                                  |   |  |                          |
                                  V   |  V                          V
                                +----------+                  +-----------+
                                |          |-----requests---->|   Client  |
                                |Components|                  |  Request  |
                                |          |<----replies------|  Manager  |
                                +----------+                  +-----------+
                                                                    ^
                                                                    |
                                                                    |
                                                                    |
                                                                    V
                                                              +-----------+
                                                              |    User   |
                                                              | Interface |
                                                              |           |
                                                              +-----------+
    

In this diagram, the general structure of the proposed system is shown.

The Database Server provides a single point of entry to the database. It must carry out the following functions:

1. Control of what gets added to the database, including flagging conflicts in the case of dual updates.
2. Maintaining a list of which components are interested in which parts of the database.
3. Feeding data and / or updates to interested components.

All communication to and from the database manager will be in the form of XML fragments, which will correspond to named regions in the XML DTD.

These fragments will be either a simple fragment, in the case of an add, delete or request for a copy of data, or a fragment pair (before / after) in the case of an update request or notification.

Fragments returned from the database manager may be either the full fragment or a subset of its components. In this way a component could request continuous updates of the entire kite, but only recieve deltas of the parts that have changed.

The Component manager instantiates and destroys components, and feeds requests and replies to and from the relevant components and the client request manager.

The client request manager handles the client request API, which defines the interface to the server side of the system from the user interface. Requests may come in to this from both UI components and the server-side components as well. Thus, if a component requires another component to act, it will request this through the client request manager.

The components for the processing core of the system Each component must do the following:

1. Register themselves, and their purpose, with the component manager. This information will be used by the Component manager in order to route requests to the relevant components.
2. Carry out their relevant function, and send the reply to the component manager. Any errors will be propagated up to the client as necessary.

As mentioned, components may act as clients in their own right. Thus a component may ask for a function to be carried out, but not care how it is carried out. The components in the system are therefore very loosely coupled, and can be changed on an 'ad hoc' basis.

Notes

[1] These requirements are very high level, and don't cover nearly enough detail to start work yet.

[2] This is so that certain tasks can be isolated - I'm thinking particularly about the 'parts layout' functionality, which is applicable to more than just kite design. Hell, we could sell that, if we weren't going GPL.

[3] Any predeveloped libraries we use should be covered by the GPL or similar, and should have the same technology restrictions. Moreover, they should have as few dependencies on other libraries as possible (if you've ever tried to compile 'Enlightenment', you'll understand _exactly_ why)