R3 DevBase Design Concepts
Return to: R3 DevBase Chat Forum
Why did we build DevBase? The requirements of the system were documented in Better Developer Communications on 20-Nov-2008.
To meet these requirements, the system was designed with the features below.
We want users to be able to access the message system from anywhere. That includes:
|REBOL CLI||command line interface - so even users on remote server shells can see messages.|
|REBOL GUI||graphical user interface - the easiest to use.|
|Web||as a normal HTML web page - so people anywhere can view it, and also find it in Google.|
|Web Mobile||light-styled for cell phones - for rebolers-on-the-go.|
|as a subscription/publication list - for people who find email convenient.|
Headings provide the main structure for postings and navigation by subject.
New headings at any level can be added as needed.
Messages can be attached to anything, not just headings.
For example, a message can be attached to a file submission so users can discuss issues related to the submission and keep them within the context of the file itself.
Another example: a messages can be attached to an alert, for example to provide additional information or conditions.
In the future, messages will be allowed for projects, tasks, calendar events, and more (all using the same general mechanism).
Alerts and Banners
Alerts and banners are special messages designed to get the attention of users.
An alert is a message of urgent importance and will "popup" to be sure that the user sees it. In the CLI client, it will be shown automatically.
A banner is a message that labels or defines a section, such as a heading. It's main purpose is to help keep a discussion on a defined topic. For example, a heading called "Button Shapes" in a GUI section may have a banner that says "This section explains how to make different button shapes."
Private messages are those that can be read only by specific users.
Note that private messages can be posted in any discussion thread, even in public discussions. This allows users to make comments to other users, but keep them within the context of the discussion.
For example, in the Button Shapes discussion above, Mario might privately tell Luke: "I prefer to make buttons with rounded corners." Only Mario and Luke will see that message.
Special tags can be attached to messages.
Tags are often used to indicate messages that are important in some way. Maybe they need a resolution, an expert reply, or an official decision.
With tags, the message base is easily searched for those important messages.
Also, a message can have any number of tags, tags also include the user who issued the tag, and the date it was issued.
The ability to see all new messages regardless of heading or type.
This provides a simple way to say, "show me everything that's been posted recently". You will see not only messages, but new headings, new users, new alerts, new files, etc.
Selecting an item (message or heading) from the list will automatically locate you to that context directly (under the relevant headings.)
Any message, heading, alert, and everything else is referenced by a unique number.
For example, you can tell a user to "please read message #1020" or "go to heading #320".
In addition, these numbers provide each entry a unique URL address, allowing it to be referenced throughout the Internet.
This is a trust mechanism to help reduce chaos and limit abuse.
For example, not every new user can create a heading or post an alert. Doing so requires specific ranks.
All users begin with low rank (untrusted) and advance via higher other ranked users.
In addition to the above features, there were also a few technology requirements:
- HTTP Gateway
to allow access even from subnets that restrict direct port connections (due to bandwidth or security concerns).
- Lightweight DB
use of a very lightweight homogeneous database model that can associate via tagging any record with any other record.
- Super-lean server
requires only an HTTP server running CGI (as a proxy). No other special packages, modules, or databases are necessary.
- Server logs
server logs all events and actions, and auto-generates user-viewable messages for primary events like user creation.
- REBOL-based technology
drink our own wine.