Bookmarks Design Document

by Cynthia Kiser

I. Essentials:

II. Introduction:

One of the most annoying things about having ready access to many personal computers is that something you need inevitably ends up trapped on the other machine. In encouraging users to store more of their useful information on an ACS web service, we can increase it's usefulness and hopefully increase "site stickiness". The ability to view other people's bookmarks and to make some or all of one's own bookmarks publically visible can encourage community sharing of knowledge.

This application allows the user to add individual bookmarks by hand or upload their entire Netscape bookmark file - IE users are offered a tool that they can use to convert their directory of individual shortcuts to a Netscape-style bookmarks file. Once the bookmarks (and folders) are entered into the system, users can move bookmarks within the folder structure. One can test individual or multiple links to see if they are still responding and delete dead or unwanted bookmarks. By default bookmarks are public - a person may mark individual bookmarks or entire folders of bookmarks as private.

To facilitate collaboration within communities, bookmarks default to public and users can view all the public bookmarks for the site - by individual user or sorted by popularity. The most poular domains are also listed.

Limitations of the current system:

III. Historical Considerations

There are notes in the data model indicating that originally a bookmark folder was a tree built by Oracle's connect by function - but I think this was changed before the original application release because it would be too slow to build if the bookmark file got reasonably complex.

IV. Competitive Analysis

V. Design trade offs

As discussed in the data model section, the sort key scheme used for bookmarks is an adaptation of the one originally employed for bboards. Each level of hierarchy adds 3 digits to the sort key and the keys are sorted alphanumerically give one the sort order within a level. The benefit of this scheme is that sorting these keys alphanumerically allows one to rapidly generate an arbitrarily deep hierarchy without significantly increasing the time it takes to construct. If the nested hierarchy were to be implemented by an Oracle connect by this would rapidly become unweildly to pull out of the database.

The drawback of this scheme is that it is difficult to do anything except append something to the tail end of that level of the hierarchy. Re-sorting bookmarks within a folder involves recalculating all the sort keys from the point of insertion onwards. That is not so bad - except if one of the affected entries is not a bookmark but a folder. Then all of the entries within that folder (bookmarks or subfolders) will have to have the last 3 digits of their sort key updated to reflect the new position of their parent folder. That still does not sound so bad - but what about subfolders within that folder? then we have to update 3 digits within the parent sort key. And so on. That is why despite the desirability of sorting bookmarks within folders that feature has not been implemented.

VI. Data Model

Bookmarks data model is basically 2 tables - one for the URLs, bm_urls and one mapping urls to the user's bookmark page, bm_list. bm_urls stores the url, domain (for quick calculation of popularity of specific domains), info about their content (keywords and desctriptions to use for searching), the date the status of the bookmark was last checked, and the date it was last reached.

For a bookmark to be included on a user's bookmark page, a row is written to bm_list mapping the url to the user and indicating its position in the hierarchy of their bookmark tree. Folders are designated with folder_p and can either be shown open or closed; the fact that the display state of the folder is stored in the database means that it persists across browser sessions - good if you want to come back and see things as you left it - except of course if someone else was browsing your bookmarks and left open one of the folders you usually leave closed!!! To supress the visiblity of bookmarks within closed folders, those bookmark records have their in_closed_p column marked `t'.

Sorting of bookmarks into folders is handled by a scheme that stores the sort order in a string calculated at insertion time that alphanumerically sorts in the correct fashion. For each level of hierarchy, one adds an additional 3 digits to the sort key, thus the level of nesting of a url/folder entry can be found from length(parent_sort_key || local_sort_key)/3. Since one only wants to increment the last triple of the sort key in order to add a new entry to a folder, the original author chose to save the the actual sort key in 2 columns, the parent and local sort keys. New sublevels are created by concatenating the parent_sort_key and local_sort_key and using that as the parent key for the entries at the next lower level. PL/SQL functions have been provided that calculate the next sort key in a sequence - we need this because the 3 character string that is the sort_key contains each of 0-9, A-Z, a-z.

Bookmarks can be public or private (private_p = 't'). To deal with public bookmarks that are within folders that are marked private the hidden flag is `t' if a public bookmark is within a private folder (to be clarified).

In the first iterations of this application, there were indices defined on composite keys - this actually slowed matters down considerably. These have been replaced by indices on all columns with foreign key constraints - e.g. index the parent_id in bm_list.

VII. Legal transactions

VIII. API

PL/SQL functions for sorting:

IX. UI

X. Configuration parameters

Except for the parameter that limits the size of the bookmark file that may be uploaded, all of the configuration parameters for this application are cosmetic: system owner, system name, html tags for indicating private and dead links, folder and file colors.

XI. Acceptance tests

XII. Future Improvements/Areas of Likely Change

XIII. Authors:


Advertisements