Design Goals

The high-level goals of the design of Tigris are the following:

• Produce simple, easy to use, practical, useful tools for open source developers. User interface maters.
• Implement those tools in a way that is secure, reliable, and efficent.
• Produce a package which is replicatable: it can be fairly easily installed on several machines. This means Java with a minimum of prequisite libraries.
• Keep the implementation understandable and maintainable. Again, this means java, good documentation, simple, clean, well-thought-out design.
• Produce a reusable framework of collaboration components to make actual application development faster and easier.

We propose to implement the following collaborative components. The schedule will be worked out such that component are done as needed for each application. Each component will be displayed in a "box" on a web page and is parameterized to customisze it to the use at hand. Ideally, standard components could be added to a page simply by editing the WebMacro template file for that page.

These boxes should support for skins: a look and feel that is specified once and applied consistently to all elements. For example, the font, size, and color of box headlines.

Not all the parameters are speced out. Some are given as examples.

• List box displays a list of rows based on a database query. The first N items are displayed within the box, additional items may be accessed via a "more" link. This is the real work-horse component, if it is made flexible it could be used for the majority of application needs.
  • Title: a string to put in top of box.
  • Query: SQL query.
  • ItemColumn: which result column to display.
  • ItemMacro: WM macro text to use for each item in the result.
  • ValueCoulmn: which result column to sort on.
  • SortingRule
  • N: number of items displayed in box
  • EmptyMessage: alternative text to show if query returns no results
  • MoreLinkText: label for "more" link, empty string if no "more" link
• Tree box displays an indented list representing a tree data structure.
  • Root: a query to find the root(s) of the tree
  • ChildRule: a rule to find the children of a given node in the tree. Expressed as a java class or SQL query. Maybe alternative child rules could be selected from a drop-down list. This is similar to ArgoUML.
  • VisibleDepth: number of tree levels to show in the box. Clicking on a link may drill-down by leading to another page with another tree view.
• Survey box displays a survey question and prompts for response. Survey questions and possible answers are drawn from the database.
• Search box displays a search text entry field and "search button. Allows the scope of the search to be specified.
• Query box prompts for some parameters and runs a query against the database. Much of the query is specified in the parameters to the query box.
• Result table box displays query results in a simple table format.
• Broadcast box displays a message from the system admin if one is currently specified. For example, "The system is going down in 10 minutes."
• Nav box special case of a Tree box where each item is a URL and the current URL is displayed in a special way. For example, current location is bold non-link, other locations are regular links.
• Discussion box shows what other people have said and offers the user a chance to add a comment. This may actually be a combination of a list box and a data entry box.
• Vote box allows the user to cast a vote for a particular object. Usually the object described on the same page. Users may have a given number of votes in each category. Vote should tell the user how many votes they have left to spend, and allow them go to a page to view and change their existing votes. Should also show the number of votes other people have assigned to the object at hand and its rank.
• Rating box allows users to rate the object at hand. Similar to survey boxes, except that the responses are recorded based on the "question" and the object ID of the object at hand.
• VisTree box shows a set of nested rectagles to visualize a weighted tree. For example, the number of lines in each souce file in a srouce code tree. Or alternatively, the number of bugs reported against each source file. Or the number of uncommented methods in each source file.

Aside from the "widgets" of the collaborative framework, there need to be some other pervasive services:

• Uniform object IDs for each object of interest so that it can always be refered to unambiguously regardless of type or vhost.
• Notifications users can subscribe to be notified of changes in certain objects. Notification messages can be accumulated and sent in batches to a given user as a digest.
• Depenencies keep track of which other object need to be updated once the given object is modified.
• Subscriptions allow users to specify the notifications that they want. Users can also subscribe to an object. For example, subscribing to a FAQ with a period of once a week would give a user an email with the complete FAQ once a week. This can also allow users to subscribe to "standing queries", for example, "show me my bugs".

• FAQ-o-matic: Basically a tree box to navigate questions. Data entry page is used to enter new questions or answers. Users may vote on questions that they would most like to see anwered. Users may rate answers. Answers displayed in a list box ordered by ratings. Users may subscribe to a FAQ question or category to be notified if a new answer is ever supplied or a new question added.
• Bug Tracker: Consists of data entry and queries. Also, each bug report has a discussion box showing comments related to that bug. Bugs can depend on each other, or on source code modules. The bug reporter and any assigned developers are automatically subscribed for notifications about changes in the bug. Bug reports can be voted for. When a developer sees his/her personal home page, it may have a query result table box showing bugs assigned to or reported by him/her. Bugzilla whining is a form of subscription.
• Cookbook: A simple kind of HOW-TO documentation telling developers how to do certain types of enhancements or contributions. The steps are basically a list box. There could be a discussion around each cookbook recipe.
• To Do Lists: These are lists of "to do" items. Personal "to do" lists are basically a list box. The project "to do" list may be a simple list box or a tree box. Alternative sorting rules, sort columns, etc. can give some degree of customization.
• Source code browsing: Before the developer gets to the level of actual source code, he/she may drill down through a variety of source code organizations. For example, a tree box with a child rule showing the files in a given directory. Alternatively, the user may want to drill down through an inheritence hierarchy, or a list box of classes implemented by a given developer. Queries done against the source code database may be shown in result table boxes. Users may subscribe to a file to be notified of any changes to it. They could subscribe to the class inheritence hierarch (or part of it) to be sent notifcations or periodic reports on the that organizational structure.