The Forum Browser
There are two options here. We can try to make each UIO of the Browser an independent one that can do everything by itself, or we can make one UIO the Parent object that is in charge of all of its children.
There is definitely something to be said for both, and we should investigate both approaches to determine which is the most effective one.
Having each UIO be completely independent and equal seems elegant. It may seem inefficient at first if all the code needs to be replicated, but making it a true object would allow a single object code to handle all its instances and therefore just become more efficient instead. If there are items we need to share, we try doing this by creating a different UIO for it. For instance, a Forum can be used without logging in, but there is extra functionality available if you do log in. We will deal with the situation for now where we are not logged in, but maybe a separate login object could/should take care of logging in, and other UIOs could reference it. We’ll have to consider carefully how we go about something like that, at some point, but for now we’ll stick with reusable objects.
On the other hand, there are some things we may want to cache, like the forum database connection, including login data.
Let’s try the full object approach by default, and see about the other option when we run into a brick wall somewhere.
Basically, we are going to create a Forum Browser UIO that can display itself and all its children, and spawn children.
Let’s start with the absolute basics. We have forums, subforums, threads and posts. So, these are the main types our object will have to be able to render. Furthermore, each has a unique identifier for the database, a subject, created by user, creation date. Some of the objects have a few extra items, such as ratings and number of posts (threads).
Starting with the Forum, once activated it will immediately spawn a child for each of its subforums or threads. Each thread will spawn a child for its first post, and each post will spawn a child for the next post.
To help navigation, we will have to deal with situations where a lot of children are present. A forum may for instance contain hundreds of threads. For this, we could create an inbetween object that allows sorting, searching, and grouping of threads. For now though, we will keep it simple and just take the 5 latest threads. In case of posts, we will offer the first post and the first unread post.
So, what does our Browser Object have to do?
1. The Forum Browser Object (FBO) is loaded by the MAO
2. The FBO receives an activation message (you have been selected) and a default configuration message from the MAO, containing its basic settings (available pixel dimensions)
3. The FBO renders its 3D Mesh data representing itself as ‘selected’ and returns them to the MAO
4. The MAO draws the 3D Mesh data and then waits for User Input.
The user has principally these options: activate the object, select another object (sibling), tell the user-interface to zoom in or out, and ask the object to display its children, if it has any.
5. The User tells the MAO that it wants the FBO to display its children.
6. The FBO contacts the Forum database to retrieve its children (Subforums and/or the first 5 threads)
7. The Forum creates XML descriptions of these children and passes the MAO a message that it has children ready to show.
8. The MAO takes the descriptions of the Child nodes, and repeats step 1-4, taking a default setting from the children data to choose which one will receive focus (‘selected’).
Some Detailed considerations for each step
1. The Forum Browser Object will be ‘installed’ with about the same data as it would provide as xml child descriptions when displaying children. It could simply contain a link to the website with the forum where it can get its own forum specific configuration data (the forum could provide the 3D Mesh for a number of things, including its own representation, user icons, etc.), or the forum could even provide its own forum object, with its own unique features and so on. When none of these are supported, we can have a generic Forum Browser Object that provides most of the features in a neutral manner.
2. The exact information here will vary as we move along in the project. I expect we’ll get options like ‘selected’, ‘option’ (when it is one of a number of options the user can choose between), ‘selected option’, ‘activate’, ‘children requested’, and ‘end’. But lets for now only deal with selected, not selected, and activated.
3. Seems fairly straightforward – just look at what state you need to render yourself in (child, selected, activated) and return the relevant 3D data. During active and selected states, however, the MAO will keep polling the object for visual updates, and the selected object could be rotating or otherwise animating. , but of course we’ll have to pick a decent file format to use with this. Perhaps there is an existing, open standard we can use, but more likely we’ll have to devise our own, because we need a way to indicate which effect applies to which element, and we are likely to come up with completely new effects every now and then. I’m sure we can come up with something convenient.
4. There are a number of control configurations possible. Right now I am thinking we could use the mouse for zooming in/out and titling the view, and the keys for navigating through the children and siblings. Ideally, we also come up with a way that requires only the up/down/right/left and enter/escape as input, with auto zoom options.
5 onwards. Pressing the down arrow could be used to tell the MAO to display children. This could be a context sensitive command – if the children had already been visible, then the focus would move to the default child instead and the MAO would take it from there. F
6. This is the point where we do some actual talking to the forum and retrieve the xml descriptions of the subforums/threads/posts. We then convert these to the children xml description for the MAO, which will include parameters for the FBO exactly as they were in step 1.
Some technical considerations of the implementation will come next. We could make this single threaded for instance, to start with. In this case, when the FBO gains full control, it could receive a pointer to the routine on the MAO where it needs to deposit its updated Mesh data for screen updating. Alternatively, the FBO and any UIO could have default input/output routines that the MAO accesses. For instance, in active mode, it just cycles through the UIO ‘active loop’ routine, taking care of the UIO’s main loop.
Feel free to disagree, comment, question, anything I wrote so far. I'm going fast, and therefore I may appear to be going solo, but that is not my intention. I'm just contributing to the project, and trying to make it really happen.