1vU##$%%&InterMix Web Specifications Version 0.60 1. General Design Document Conventions and Verbiage Environment Layers - MixHost.exe * QueueThread - RequestThreads and States -- Logging In / Homepage -- Users - User Levels & Privileges -- Hubs -- Cookies -- Areas - Lookups - Public & Private Areas - Documents -- The Document Path -- Physical Storage of Documents Attaching Files To Documents - Uploading and Downloading - MixTextDoc - The Generic Message Document Document Operations -- Deleting Documents - Copying Documents -- Tracking Read/Unread status of documents * The Recommender * Recommender Extentions + Recommender Organization -- Recommender Form Features + Recommender Reply Forwarding + Ratings Visit Lists - Direct InterMix Database Access + InterMix List Server + HTML Page Customization Inbox - Outbox - What's Hot Daily Maintenance Thread Archive Messages Calculate Top10%, Top1/3, Bottom10% for each area Calculate Hot Threads for each area Calculate Hot Areas Purge read/unread buffers 2. The InterMix Data Engine - MixEngine MixItem Class General Data Interface Methods Parameter Types Key-Value Blocks Versions Public Methods QueryEngine Class 3. Database Definitions For each table: Name Fields Name Type Length Default value Validation Minimum Maximum Indexes Primary Secondary Relations 4. Classes For each base class Base Class definition SubClass definition 5. Interfaces HTML Client GlobalMix LEGEND: * Modified documentation + New documentation --- Section modified or added in last version -- Section modified or added two versions ago - Section modified or added three versions ago ------------------------------------------------------------------------------------------------------------------------------------------- 1. General Document conventions: All references to numeric or ASCII values are of the decimal format. Unqualified references to "Homepage" indicate an InterMix generated page. InterMix hubs each have one Homepage. The terms "document" and "message" are used almost interchangeably. A message is a particular type of document. Environment: Development Language: Delphi 2.0 Database Type: Paradox 7 CGI: Version 1.1 first. Special server APIs later. HTML 2.0 Platform: Windows 95 or Windows NT Layers: InterMix access is separated into a number of layers. This modular design is necessitated by the different methods of access and due to the nature of HTTP CGI applications in general. During an InterMix request, there are three relevant processes running on the host machine: 1. WWW Server - invokes a new instance of MixStub.exe for each standard CGI request. Standard CGI protocols invoke a new executable process for every CGI request. Each server may have a proprietary API to eliminate step 2, but those will be addressed at a later time. 2. MixStub.exe - one instance of this small program is active for every active CGI request. This "stub" is executed by the WWW Server. All stubs communicate with MixHost.exe, which is running continuously. MixStub.exe is passed parameters from the HTTP Server. These parameters must be passed along to MixHost.exe, but not directly. The most efficient way for the stub to communicate with the host is through a memory mapped file (WIN32 API). The memory mapped file is visible to all processes, and is the only 32 bit Windows mechanism which allows direct sharing of memory segments. The memory mapped file is first locked via the use of a mutex (WIN32 API). Once the lock is obtained, the memory mapped file is filled with the request data gathered from MixStub.exe. Awindows API message is next sent to MixHost.exe, flagging that a request has been loaded. 3. MixHost.exe - The InterMix server application which is running continuously. One instance of MixHost.exe handles all hubs. For example, there may be "Auto Collectors" , "Movie Site", and a "Civic Issues" hubs all running on the same HTTP server. All three hubs are handled by the one instance of MixHost.exe. Once MixHost.exe receives the "Request Pending" message from MixStub.exe, the request is taken from the memory mapped file, and the mutex is cleared, indicating that another CGI request may be queued. The request is processed, and an HTML file is generated. MixStub.exe is then informed (via a WIN32 event) that the request has been processed. MixStub.exe then terminates, signalling the HTTP server that the process is complete and to return the fresh HTML file back to the web surfer. MixHost.exe: MixHost has many continuous threads. One thread, named QueueThread, is dedicated to communicating with the different instances of MixStub.exe and delegating tasks to special "RequestThreads". MixHost.exe will be able to handle multiple simultaneous requests. These requests are processed through parallel threads of the same type: RequestThread. Their job is to process the CGI parameters and return an HTML page. At any given time there is the same number of active RequestThread threads. Each active RequestThread can be either busy or idle. The number of active RequestThreads for each hub is controlled by the system administrator. QueueThread runs as an event loop. It waits (efficiently) for a message from either a MixStub.exe instance or a RequestThread. QueueThread sees requests from MixStub.exe and selects an available RequestThread to handle the request. If there is no available RequestThread, then QueueThread waits for the "done" message from the first available RequestThread. Consider the following model: Server --> MixStub.exe <--> MixHost.exe(QueueThread) Communication between the server and the CGI stub (MixStub.exe) is one-way, from the Server to the CGI stub. The server considers the CGI to have completed its task upon the CGI termination. Upon return, the resulting HTML return page is assumed to exist as a temporary file, named by the http server when calling MixStub.exe ("temp0001.htm" in the example). This HTML file is then sent back to the web client by the http server. MixStub.exe communicates directly with the appropriate HubThread's QueueThread Each client request contains the target hub. For example, when clicking on an InterMix link, the URL itself contains query information pertaining to the appropriate hub. A (partial) URL could look like "...mixhost.exe?hub=TechSupport...". MixStub.exe uses this "TechSupport" information to find the appropriate Windows API memory mapped file. Memory mapped files are the medium for communication between a hub's QueueThread and MixStub.exe. Bookmarking is taken into consideration concerning InterMix URL design. In addition to other variables, the URL contains a reference to the object a page has in focus. If a page is displaying an area's document, the document's MixID is embedded in the URL. Using this attribute, an InterMix page may be bookmarked (browser level) and later revisited. During a subsequent visit to this bookmark, the Session-ID will have fallen from visibility, so the context of the screen is not known. This includes the user's identification. Therefor, an InterMix page generated from an old bookmark will exclude most features such as Next, Previous, Reply, Rate... Communication between the MixStub.exe and MixHost.exe is two-way. As described above, this two-way communication is facilitated through a memory mapped file, messages, mutexes and events. MixStub.exe returns a timeout message when its request has not been processed for a (sysop controlled) period of time. Next is the model of the running InterMix host with its (always active) threads: MixHost.exe HubThread (hub "A" - see hub"C") HubThread (hub "B" - see hub"C") HubThread (hub "C") | |----- QueueThread <--> MixStub.exe | | <--> LocalUserThread ** | | <--> ActiveX Interface (Ver. 2.0) | | | |----- RequestThread | |----- RequestThread | |----- RequestThread... | |----- LocalUserThread ** | |----- MaintenanceThread | |----- IndexThread |----- RatingAnalysisThread |----- InterMixToInterMixThread (Ver. 3.0) |----- CompactionThread |----- AutomaticKeywordThread... Notice the outer framework around each hub (HubThreads). MixHost.exe is the outer process which houses and controls all hubs. Each hub runs in its own thread, and it is completely independent from the other hubs. The Sysop can start and stop the hubs and adjust the number of active threads without bringing MixHost down. The hubs do not communicate with each other. Each one is run in its own multitasked threaded environment. This type of architecture has been chosen to simplify the task of running multiple hubs on one machine. One visible process runs on the server rather than three when three hubs are a used on the web site. This structure also offers memory saving benefits. In addition to the previous thread structure, there is a repository of client states. This allows the server to store the client's current page information on the server. On initial entry to an InterMix Opening Page the client is assigned a client-id. The client-id is a 6 character alpha-numeric identifier which the client carries from InterMix page to InterMix page during the session. This is a value which is embedded in the URL. Therefor the web client may send the host application very simple requests (saving bandwidth), and MixHost.exe will know the context of the request and act accordingly. For example, the user may click the "Next Page" button on a message list. Because the user's page state is saved, MixHost requires no more than the Client-id, the Page-id and the "Next Page" message. The maintenance thread can invoke new low-priority threads of its own, including index integrity checking, rating analysis and special threads to communicate with other InterMix hubs. These special InterMix-to-InterMix threads can manage such tasks as updating ratings and mirroring areas (forums) and Recommender data. QueueThread: QueueThread's primary job is to collect and pass requests to an idle RequestThread. QueueThread receives these requests by one of the following methods: 1. Receives a Windows API Message from a MixStub.exe process. 2. Receives a Windows API Message from the hub's local user interface. In addition to managing MixStub.exe requests, the QueueThread thread also handles requests from the local interface and eventually calls from the server APIs. The local interface (LocalUserThread) runs in its own thread. Initially it will contain one window with a "shutdown" button. A later version will provide a more functionality such as administrative and sysop functions. Local interface requests into MixQueue get top priority, but no local interface data oriented features are planned for version 1.0. RequestThreads and States: RequestThreads are always active. There are a fixed number of RequestThreads for each hub, and this number is under control of the sysop. This allows multiple requests to be handled simultaneously. When not busy servicing a request, each RequestThread awaits a message from QueueThread. Once a RequestThread has been awakened, it interprets the request origin and invokes the appropriate handler. The handlers are currently planned for three different types: HTML (InterMix Version 1.0), Thin-Client ** (Version 2.0) and GlobalMix & Thick Client ** (Version 3.0). The HTML method will be the most complex and involved, as it will be responsible for generating entire HTML documents on-the-fly. GlobalMix is the method in which remote InterMix hosts communicate via the internet. This is used primarily for one host to send a query to many other hosts simultaneously. The results from all of the hosts will be collected by the calling-host and returned to the client in one cohesive package. The Client interface will provide a means for client applications to communicate with MixHosts. The first client type will probably be a Java implementation. The three interface handlers have the class names: HTMLInterface, ClientInterface and GlobalMixInterface. ** The Thin Client version will feature an interface consisting of distributed Java (most probable) Applets. The Thick Client version will consist of a platform specific program, designed to query InterMix Hosts and provide its own interface. It will also maintain its own database, which could be put online as a hub. This technology is similar to the popular PointCast software. The most crucial element of each RequestThread is its link to MixEngine, a class providing data access. Each RequestThread owns an instance of MixEngine - One MixEngine for every RequestThread. MixEngine is non-visual and is not concerned about the source of requests, whether HTML, Client or GlobalMix. Each interface class directly communicates with the MixEngine instance. The communication model of each RequestThread: RequestThread <--> Interface <--> MixEngine The intermediate "Interface" class will be one of the following: HTMLInterface ClientInterface GlobalMixInterface LocalInterface The "state" can be thought of as the specific properties of a client's session. Because HTTP/CGI is a stateless protocol, InterMix must provide its own mechanism for remembering clients and their states from request to request. The HTTP server receives a request from a www client, hands the request to the CGI process, returns the HTML generated by CGI and the discards the association with the client. InterMix cannot be so detached, so InterMix uses a state-saving scheme. Invariably, InterMix saves the state of the client's MixEngine properties. These properties include user defined filters, the document-in-view and queries results (plus much more). The HTML Interface uses its own state-saving repository as well. Naturally, this type of state contains items such as user preferences and properties affecting the interface implementation. Hence, this document will refer to both MixEngine-state and interface-state. It is important to understand that InterMix separates the back-end data engine from the interface implementation, adhering to a true client/server model. Even though the data engine and interface are contained within the same physical program, they are shielded from one another, and either may be cleanly extracted. It would be possible to have a pure InterMix database server running as a separate process, like Oracle for example, but one all-encompassing application provides more efficiency and simplicity for the end user. InterMix could actually exist as many separate applications - one process for each hub and one process for each data engine instance (plus more), but we have chosen to put everything under the same hood. Many thanks goes to Win32's multi threading technology. Back to RequestThread. RequestThread first informs MixEngine to recall the MixEngine-state of the requesting-client's referring page. The referring page is ascertained through the "page-id" variable, which is sent from the client. This state is recalled so that MixEngine has a reference to the context of the incoming request. Next the appropriate Interface class is called with this request. In the case of the HTML Interface class, the class first recalls its own state information based on the page-id. The page-id is the unique identifier of the existing page which the request was launched from. Again, the state information sets the context of a request. The Interface class may make any number of calls to MixEngine to generate the new page. Upon completion of the return page, this new page is assigned a new and unique page-id, which is imbedded in the document. The interface class is then responsible for saving its own state with this new page-id. The interface class next informs RequestThread of completion (through a thread-to-thread Windows API Message). The RequestThread then informs InterMix Engine to save its current state with the new page-id. The following is the activity of a typical RequestThread when being assigned a task: Typical RequestThread Activity ------------------------------------------- Idle (waiting for a Windows API Message) Receives request from QueueThread - Request includes Client-ID, Page-ID, plus request details. RequestThread Informs MixEngine to recall state based on the Page-ID. Checks request origin type. Finds that the request is of HTML origin. Invokes HTMLInterface with the request information. Request is "show the message list for area 'xyz' ". HTMLInterface recalls interface-state information based on the passed Page-ID. HTMLInterface makes one or more call into MixEngine. HTMLInterface uses data returned from MixEngine to generate an HTML form ('xyz' message-list). HTMLInterface saves new state information based on the Page-ID of the new page. HTMLInterface returns to RequestThread. RequestThread informs MixEngine to save its state based on the new Page-ID. RequestThread notifies QueueThread (via Windows API Message) that the task is finished. QueueThread sends a "done" event message to the provoking MixStub.exe CGI process. Idle Notes on parameters: *** Client-id uniquely identifies the user. It's assigned at the beginning of a session and is good for one session only. MixHost.exe is able to track the user-id of the client through the Client-id value. The Client-id is eventually reused after the six digit id flips. The client-id may also be used to track state information pertaining to general session information and not specific page states. *** Page-id identifies the page which the request was launched from. The Page-id is also a unique six digit identifier. Each page generated by InterMix is assigned a new unique Page-id. The client passes the Page-id value to MixHost.exe whenever the a request is made, and this value is used to recall state information relative to that page. Page-id allows the HTML user to "go back" with the browser a few pages and then make a new request from an old page. Not only is the current page's state available, but recent pages are kept as well. *** Request info may consist of one or more parameters, depending on the request type. Parameters are always passed in a string of key=value lines such as in an .ini file. The LocalInterface class is not to be confused with the LocalUserThread. LocalUserThread provides the local visual interface and calls RequestThread for data access. RequestThread in turn calls the LocalInterface class which calls the MixEngine class. The LocalUserThread--->RequestThread--->LocalInterface-->MixEngine call chain simply enables the local user to access the MixEngine class. Please note that it would be very possible for LocalUserThread to own its own instance of the MixEngine class, thus eliminating the need to use the RequestThread and LocalInterface classes. However, this method would lead to a waste of resources, wasteful because each instance of the MixEngine class is taxing to both memory and open files, which leads into the next issue. RequestThread instances are static. These threads are not created and destroyed for each request. They are aware of any specific client only during the time which a RequestThread is servicing that client's request. Page states are cached (in a repository), and they are recalled upon the next request made from that particular page, and the page is identified through the page-ID. MixEngine saves and recalls state information, and the HTML interface saves and recalls its own state information. This method allows one or more RequestThreads to service many active clients. For example, five RequestThreads might handle a hundred active clients, but only five simultaneously. A sixth client request would be queued until a RequestThread becomes available. The reason for not closing RequestThreads when idle is simple. An instance of the MixEngine class is owned by each RequestThread. Each MixEngine object (class instance) requires many files to be open - opened uniquely by each object. The opening and closing of each file is relatively slow, and performance would greatly suffer if each file was opened and closed each time MixEngine was invoked. It's the same concept as having MixHost.exe continuously running as opposed to having MixStub.exe perform everything itself.. HTML Interface: Communication between the web browser and MixHost.exe is facilitated though CGI, which is a standard protocol of the web server. The CGI protocol passes many parameters to the "CGI" application, one of which is the HTML version of the client. The InterMix HTML class may use this information when formatting the return pages. Logging In / Homepage: The Homepage is the opening page for each InterMix hub. This page contains "Auto Session" buttons, a "What's Hot" button, an "All Areas" button, links to other InterMix hubs and customized text. The Homepage which the anonymous user sees contains a "Login" button. Clicking this button brings the user to a login/registration page. After logging in, the user is returned to the Homepage. After logging in, the "Login" button still appears and supplies a convenient way to re-log in as a different user. The Inbox and Outbox buttons are only available on the Homepage of the user who has logged in. More on Inbox and Outbox in a later section. In addition to the above Homepage elements, the sysop may implement direct links to certain areas. This could be useful for very popular areas and "Bulletin" type areas. The button text of the Homepage is customizable by the sysop. For example, the "All Areas" button could be renamed to "Forum Index", "Area List" or "Discussion Groups". In addition to the above buttons, the logged-in user's Homepage contains an "Inbox" button and an "Outbox" button. More on these later. The logged-in user's page also shows a "Send mail" button. It is possible, though, for an anonymous user to send mail, but this is under control of the sysop. These sysop settings are: "Anonymous user may email to (1) Nobody (2) Anybody (3) Sysop only". The system administrator (Sysop) controls the accessibility of the InterMix hub. "Private" hubs require users to log in. "Public" hubs may or may not require the user to log in. Users having access to a hub who have not logged in are known as "anonymous". The sysop controls privileges of the anonymous visitor. Logging in may allow special privileges such as posting, rating, filtering out previously read messages and using stored preferences. Special consideration is given to users who are switching hubs (jumping to a hub through a link from another hub). This logic is covered in the "Hubs" section of this document. When entering a hub, not coming from another hub, the user either sees a login page or the Homepage. A public hub which allows anonymous users opens with the Homepage. When a login is required, a login page will appear first before the Homepage. On a public hub, this page contains a link to a registration page. When a login is not required, the Homepage is first displayed when visiting the InterMix hub, and the visitor is anonymous until (if ever) they log in. As discussed above, the anonymous visitor's Homepage shows a "Login" button. Users: As mentioned above, users may be allowed to visit an InterMix hub anonymously or as a user with an identity. Users with an identity are allowed to choose their own user-id and password. The user-id is not to be confused with the MixID, which is a field that uniquely identifies any InterMix item, including users, across all hubs. This user-id must be unique to the hub. The hub will remember this user-id, the user's personal preferences and other user related information such as messages read by the user. The user-id is a character field of 255 characters. InterMix version 1.0 will use the first 40 characters only. The remaining 215 characters are reserved for future Internet user-identification purposes. The 40 character id is chosen by the user. This id may contain the user's email address , the user's name or an alias. The user's posts will contain his or her user-id. The user-id is NOT to contain a comma (",") character. Because InterMix accepts comma delimited lists of user-ids, this character has been prohibited. A few additional valid user-id rules: no duplicates after spaces have been squeezed, no more than one consecutive space, no non-printable characters, and the user-id must begin with a non-space character. InterMix user-ids are case insensitive Any user-id is valid except for "Anonymous". This is reserved for the anonymous user's posts. The user-id "Sysop" is reserved for the sysop only, although the sysop is not required to use this id. A user's stored information includes his or her user-id, real name, email address, personal bio, date of last update.... Each user info field has properties which are under control of the sysop. These properties are named "Required?", "Visible?" and "Propagate?". The latter two have a secondary option, "User Controls?". If "Visible?" or "Propagate?" is set to true, the sysop additionally controls whether the users themselves can hide these fields from public view. For example, the sysop may require the "Name" and "Email Address" fields. These two fields may be set to "Visible" with "User Controls?" set to true. In this case, the user can choose to hide their personal information from the world. The "Propagate?" setting controls whether or not each field will be carried over to a new hub when switching hubs and registering for the first time. If a user supplies an email address (in the email address field), it will be possible for InterMix to send Internet SMTP email directly to the user's email address. The user will have control over this option. The user may choose to keep their email address private, use an alias and still receive email from InterMix. This will promote a new level of anonymity, and may help prevent email addresses from being published. The sysop has master control of the hub, and moderators share control with the sysop over each area. When a new area is created, the moderator defaults to the user who created the area. This may be an existing moderator, the sysop or a user if the area allows users to create new sub-areas. The moderator of an area may be reassigned by the current moderator, the sysop or a moderator of a super-area. Registration: A user must first be registered before logging in with a user-id. This registration process may be performed by either the sysop or the user, depending on the type of hub. The registration process involves the selection of a unique user-id, a password and "other user information" (name, email address, telephone...). The "other user information" fields are designated by the sysop, and each field may or may not be a required entry. The above "other user information" fields will be supplied as a suggestions in a template. The sysop may also allow each field's visibility to be controlled by the user. The sysop may always see all user information fields (except password) for any user. Other users may see only information fields which are deemed visible by either the sysop or the target user. Levels of visibility were discussed in a prior paragraph in this section. User Levels & Privileges: Each progressive level of user has new privileges. Each level also has all privileges of lower level users. For example, level 9 contains all privileges of levels 1..8 plus its own set. Level User Type Privileges ------------------------------------------------------------------------------------------------------------------------------------------- 1 Anonymous Base privileges - Navigate, Read 2 Anonymous Write new documents, reply to documents 3 Registered Rate documents, Read personally addressed documents, Save settings, Hub tracks read/unread 7 CoModerator Same rights as a real Moderator. Assigned and revoked this status by a real Moderator. 8 Moderator Control of particular areas - Document operations, Modify area properties, Create subareas 9 CoSysop Same rights as the Sysop. 10 Sysop Control of all areas, Assignment of user and moderator levels, Assign Co-Sysops, Reassign Sysop status, and control of system parameters. ------------------------------------------------------------------------------------------------------------------------------------------- The sysop controls the level, 1 or 2, which the Anonymous user is assigned. The above user levels reflect the default privileges for an InterMix hub as a whole. However, more exact control may be exercised on a per-area basis. This is facilitated by allowing individual Users to be members of "Realms" and/or "Groups". Privileges may be assigned or restricted to Realms, Groups and Users on a per-area basis. A Realm is the outermost container mechanism. It contains Groups and/or individual Users. It can be analogous to a county, such as Orange County. Note, however, that Realms can overlap. The same Groups and Users may be imbedded in more than one Realm. A Group contains Users only (not other groups). A Group may belong to one or more Realms but is not required to belong to any. It can be analogous to a city, such as Santa Ana. Users are individuals, the most basic unit of identification. They may be members of Groups and Realms. They are not required to belong to any Realm or Group, although they may belong to any number of Groups or Realms. Aside from Realms/Groups/Users, the unique identifier "Everybody" may also be used. It is not required that a user be a member of any Realm or Group. They will, however, be included in the "Everybody" grouping. Types of access to each InterMix area is enabled or restricted based on Realms, Groups and Users. The following types of access apply: 1. Read privileges 2. Write (new document) privileges 3. Reply privileges 4. Rating privileges 5. Create Sub-Area 6. Manipulate documents (delete,move,copy,boot...) 7. Modify area properties (includes changing privileges) Each area's seven privilege levels owns a variable-length list of Realms/Groups/Users. Each Realm/Group/User in the each list may be either allowed or disallowed access. Such a list could look like: Writing Privileges (new root level documents) For The "Santa Ana's Mayoral Announcements" Area ------------------------------------------------------------------------------------------------------------------- Disallow Everybody Allow User "Santa Ana Mayor" Reply Privileges For The "Santa Ana's Mayoral Announcements" Area ---------------------------------------------------------------------------------- Disallow Everybody Allow Group "Santa Ana City Council" Allow User "Santa Ana Mayor" Read Privileges For The "Santa Ana's Mayoral Announcements" Area ---------------------------------------------------------------------------------- Allow Everybody Rating Privileges For The "Santa Ana's Mayoral Announcements" Area ----------------------------------------------------------------------------------- Disallow Everybody Allow Group "Santa Ana Residents" Another example illustrates an InterMix Area set up to exclude particular demographic groups: Reply Privileges For The "L.A. Non Smokers Survey" Area: --------------------------------------------------------------------- Disallow Everybody Allow Realm "L.A. County Residents" Disallow Group "Smokers" Allow User "Joe Camel" Reply Privileges For The "Non Smokers Survey" Area: --------------------------------------------------------------------- Allow Everybody Disallow Group "Smokers" "Disallow Everybody" or "Allow Everybody" should always be the first element of any privilege list. Successive entries preempt previous entries, and therefore entries should go from general (Realms) to less general (Groups) to specific (Users). If a privilege list is left blank, then the following defaults apply: 1. Read Allow Everybody 2. Write Allow Everybody 3. Reply Allow Everybody 4. Rating Allow Everybody 5. Create Sub-Area Disallow Everybody 6. Manipulate documents Disallow Everybody 7. Modify area properties Disallow Everybody if "Disallow Everybody" or "Allow Everybody" is not the first entry in a list, then "Disallow Everybody" will default if the first entry is an "Allow...", and "Allow Everybody" will default if the first entry is a "Disallow..." A newly created Sub-Area automatically inherits all privilege settings from the Super-Area. Automatic Privileges: A Moderator or CoModerator automatically has all privileges in an area. The Sysop has all privileges in all areas of the Hub. CoModerators: CoModerators are assigned by either the Moderator of an area or the Sysop. A CoModerator's status may be revoked by a Moderator, but the CoModerator may not remove the real Moderator. The CoModerator may also assign other CoModerators. Again, only the real Moderator may revoke any CoModerator's status. The Moderator or Sysop may also transfer their status to another User. Mail addressed to the "Moderator" is delivered to the real Moderator, not CoModerators. CoSysops: The Sysop may assign CoSysops. CoSysops share the same power as the real Sysop. They may assign other CoSysops and may even reassign the real Sysop position. Mail addressed to the "Sysop" is delivered to the real Sysop, not CoSysops. A User's Yes/No permission status is calculated the first time they attempt to access an area or an area's documents. This Yes/No status is then saved as part of the User's state. Successive privilege checks will be performed very quickly, as no database access is required for later checks. Each time a user orders a query (or document list) each hit is checked against their Read privileges for the document's area. If a User's privileges are changed during a session, the session must end before the changes take affect. Hubs: There are two types of hubs - public and private. Many hubs may exist on the same web server. Public hubs may or may not require the visitor to log in. Visitors not logging in will be known as "Anonymous". Private hubs require the visitor to log in. The sysop assigns a user-id and initial password for each user. The password may be later changed by the user. Special Note: The sysop can require users to use their real email address as their user-id. This is simply done on a private hub by having the sysop email the new user (to the email address they requested as their user-id) with their initial password. Local Hubs (multiple InterMix Hubs existing on the same web server) are separated by placing InterMix data sets in separate locations on the server. Coexisting hubs are aware of each other, contain links to each other, but do not share data. The URLs of the separate local hubs simply point to different hubs. To switch hubs within an InterMix session, a URL link will exist, and clicking the URL will move the visitor to either the new hub's Login/Registration Page or the new hub's Homepage. The URL will contain the encoded User-MixID, user-id and password. The new hub may already be aware of who the visitor is, in which case a login is not required. Hub switching is summarized in the following table. For clarity, public hubs requiring a login are named "Login Public". Public hubs allowing anonymous users are named "Anonymous Public". Users, in reference to the Starting hub, are either "Anonymous" or "Registered". Hub Switching: Ref. Starting hub User type Destination hub ------------------------------------------------------------------------------- 1 Public Anonymous Anonymous Public 2 Public Anonymous Login Public 3 Public Registered Anonymous Public 4 Public Registered Login Public 5 Public ANY Private 6 Private Registered Private 7 Private Registered Anonymous Public 8 Private Registered Login Public 1. Go to Destination's Homepage as Anonymous**. 2. Go to Login Page***. 3. Attempt auto-login*. If not successful, prompt user with three options - (1) Go to Homepage as Anonymous, (2) Login, (3) Auto-Register. The Auto-Register option attempts to register the user with their existing User-MixID, user-id and password. User-id clashes will be handled. If coming from a local hub, then the "other user info" will be propagated as well****. 4. Attempt auto-login*. If not successful, go to Login Page***. If registering and coming from a local hub, the "other user info" will be propagated****. 5. Go to Login Page. 6. Go to Login Page. 7. Go to Homepage as Anonymous**. 8. Go to Login Page. * Auto-login is the process of switching hubs without relogging into the new hub. First the user's MixID is searched for. If not found, then the user's user-name and password are searched for. If either the MixID or user-name/password pair match, then the user is automatically logged into the new hub and assumes the identity of the match. ** The Homepage contains a "Login" link when the user is anonymous. If the user may follows this link and log in. *** The Login Page of a public hub includes a registration option. In the event of a failed auto-login attempt, the user-id will be preset on the registration form. If coming from a local hub, all same type "other user info" fields will be propagated as well. **** "Other user info" fields: User information, like all InterMix documents, is stored in Key=Value lists. "Other user info" is in fact stored as a document. The suggested and supplied user document contains the following fields: Name(30), Email address(255), Homepage(255), Telephone(20), Address1(30), Address2(30), City(20), State(3), Postal Code(12), Country (15), and Bio(memo). The sysop may change (add, delete, modify) these fields and the appearance of the user-info form. When propagating user info from one hub to another, only fields with the same form-name will be carried over. Users may change their passwords at any time. If users is registered on multiple hubs on the same machine, they will have the option to apply the new password to all same-machine hubs. Cookies: The follow only applies to clients using Netscape Navigator. The registration form will contain a checkbox, "[x] OK to use cookies?" Checking this option will save the user's submitted profile as a "global" profile. On visits to future InterMix registration forms, like-fields will default with the current form's values. These will only be defaults, and each field's value may be changed. In addition to the global profile, using cookies will allow the user to access the hub through an "easy login". An "easy login" is when a login screen is skipped, because the server reads the remote browser's cookies and establishes an automatic login. This option should be used with care! There may be security problems with storing passwords in cookies. Areas: Areas exist in a tree type hierarchy, each area having its own characteristics and unique name. Area names must be unique within a hub. The top of the tree is an area known as "All Areas". Areas contain documents, and a query (or list) of an area returns the area's documents and documents in all subareas. This is the default type of return list, but settings can direct the query to search "no subareas" or "subareas only". A default query of "All Areas" may return documents from every area on the hub. "All Areas" itself is also a valid place to store documents, much like saving a file in a root directory. Each area has a moderator. The moderator has privileges of modifying area properties, creating subareas, deleting areas, deleting documents, moving documents to a new area, copying documents to a new area, booting documents up to their superarea, and making reply-type documents into root documents. Later the moderator may also have the duties of approving messages for posting and inviting users to join private areas. Sharing these privileges will be the moderators of superareas and the sysop. Area properties include: The area's name Moderator (user-id) Description (multi line) Primary document type (form) Reply document type (form) Default lookup (lookup name) Allow replies (yes/no) Read only (yes/no) - Only moderator or sysop may post to this type of area. Users add subareas (yes/no) Public (yes/no) Users may join (yes/no) - only if "Public" is "yes" Require/Allow/Prohibit files (yes/no) Areas have two types of documents, primary and reply. Documents are created within a form, and the same form is later used to display the document. For simple "message" type areas, both forms will be of a header & text-body format. For more advanced Recommender areas, the primary form will be of a special Recommender type, and the reply form will be of a simple "message" type. Clicking on the "New" (or "Write") button will display the primary-document-type for input. Clicking on the "Reply" button will display the reply-document-type for input. Each area contains a detailed description ("Description" property), which is under control of the moderator. Users may see this description when investigating an area. Lookups: Area Lookups: Each area contains its own default lookup. A lookup is a named set of query properties. These query properties follow: Sort type (name) Date range (All, Current or Archived) Interest range (All, Top 10%, Top 1/3, Bottom 10%) Approval range (All, Top 10%, Top 1/3, Bottom 10%) Controversy range (All, Top 10%, Top 1/3, Bottom 10%) Value range (All, Top 10%, Top 1/3, Bottom 10%) Keywords (list of keywords) Keyword list type (all or any) Unread messages only (yes/no) Root messages only (yes/no) Addressee (none,anyone,self,moderator,sysop,other) Sender (anyone,self,moderator,sysop,other) Area scope (include subareas,exclude subareas,subareas only) The user may change any of the default lookup properties of an area for a customized view of the document list. The non-anonymous user may save these modified lookup properties for automatic use upon the next visit to the area. Visit Lists: A visit list is simply a named set of queries. Each visit list item consists of: 1. An Area 2. A named Lookup 3. A "max hits" value An unlimited number of items may exist for each visit list. A typical visit list may appear like: "All Areas", "Unread By Value", 5 "Pres. Election", "By Interest", 10 "Football", "Roots By Date", 10 "All Area", "Unread With My Name", 99 This example assumes "Unread By Value", "By Interest", "Roots By Date" and "Unread With My Name" are all predefined Lookups. The first string in each line is the area name. The last element is the maximum number of documents to retrieve from the given query. All four queries will return a consecutive list of a maximum of 124 documents. Global visit lists are designed by the sysop and appear on the Homepage. User visit lists are designed by registered users and are saved for use in later sessions. Any number of visit lists may be defined, giving the user many personalized viewing scenarios. On the Homepage, user defined visit lists appear above the sysop defined visit lists. Only Sysops and Moderators may define named lookups. Users may not define named lookups, but they may set and save each area's lookup properties for their own personal use. They may also define lookups for each item on a visit list. In addition to regular InterMix Areas, visit lists may also contain entries for the Inbox and Inbox folders. Because the Inbox works differently from InterMix Areas, lookups may not be applied to Inbox lists. However, four Inbox list types may be ordered: 1. All by newest date 2. Unread Only by newest date 3. All by oldest date 4. Unread Only by oldest date Direct InterMix Database Access: This is a special feature of InterMix which allows a non-logged-in client to receive a Visit List's messages. This is useful for a site which wishes to allow general users access to InterMix documents. Like InterMix areas, Visit Lists may own a display form. When a form is associated with a Visit List, the Visit List is accessible to the outside world through Direct InterMix Database Access. Such a page is very similar to an InterMix Area's form in that it contains a static header HTML section, a static footer HTML section and a middle section reserved for dynamic InterMix content. This middle section will be a stuffed with the Visit List's documents. Documents will be separated by wide HTML bevels. This type of page is designed for the non-InterMix user. Because no logon is required for access to such a page, the usual context options will not be available - e.g. Rating, Reply, Thread... The InterMix engine may be easily requested for Direct InterMix Database Access. A simple link like the following will produce the desired page: (Note: This link may exist on any server, not just the InterMix server.) http:\\www.SomeHost.com\cgi-bin\MixStub.exe ?VisitList=BestOf;Hub=LA_Issues This preceding example produce the BestOf Visit List from the LA_Issues Hub at SomeHost.com. InterMix List Server: An Area may be designated as List Server enabled. When a document is posted to such an area, the document is automatically emailed (via SMTP) to each of the recipients on the list. A special email address must be reserved for each InterMix List Server area. The MixMaintenance thread queries each of the mailboxes periodically for new mail. Both new subjects and replies are valid forms of message authoring on the InterMix List Server. Ratings may even be achieved through replying to an InterMix List Server email and reformatting the subject line with a pair of numbers which reflect the Interest and Approval respectively. When sending a rating to the List Server, the body of the message mush remain blank. Otherwise, the reply will be accepted as valid mail and posted to the group. A rating subject list will appear like "1 0" or "3 3" or "4 -2". Public & Private Areas: As with hubs, areas may also be "public" or "private". Public areas are visible to all users. Private areas are visible to members only. A private area may be joined in one of two ways: The moderator may join a user, or a user themselves may join. The latter method may only be used if the Moderator has set the "User may join?" property to yes. A private area's name will still be visible to all, but its documents will be visible to members only. Moderators from both private and public areas may prohibit particular users from posting documents (messages). See "User Levels & Privileges" above. Documents: Documents are associated with forms. Documents contain field names and field contents. Forms contain information about displaying documents. Version 1.0's forms will be HTML code with special InterMix tags. These tags will be replaced by InterMix with live document data upon display. All documents are associated with a form type, simple as the form may be. Documents may be addressed to InterMix users or to general Internet users. The users are addressed by their user-ids, by a "moderator" checkbox or by a "sysop" checkbox. Addressing public documents is optional. Multiple users may be named as addressees by separating their User-IDs with commas, hence the "no comma in User-ID" rule. An address book may also be used for easy User-ID retrieval Any single document belongs to an area (one area only), although a reference to the document may exist in many areas. The area's properties specify the type of documents to be placed within the area. The Document Path: The Document Path is a document's named placement within the area structure. Areas are organized in a hierarchy, much the same as directories and subdirectories. The InterMix "All Area" area is similar to a root directory. Consider the following InterMix area structure: All Areas Issues News Local Events State National International Sports A document may exist in the "Events" area. It's path would be "News > Local > Events". These qualified paths never include "All Areas" unless the document's home is in "All Areas". Physical Storage of Documents: Document content will be stored in memo fields of the header records of the document (Ver 1.0). In later versions, a specialized blob-storage class will be implemented. Memo fields may be problematic and are inefficient. The blob-class is fast, secure and its contents may be packed in the background without read or write locking the class and associated disk files. Attaching Files To Documents - Uploading and Downloading: All MixTextDoc objects may own an associated file. In other words, any document can have an attached file. There is no specially separated File Uploading/Downloading area in InterMix. A file may simply be attached to any type of document. The creator of an area controls whether or not documents require, allow or prohibit attached files. Downloading is a common web based feature. A simple click on a link will invoke the downloading process. Uploading is more involved. Not all browsers allow direct uploading, and there is no way to automatically send a file with the click of the "Post" button from a "Write Document" page. This is circumvented by placing an "[ ] Attach File" checkbox in the body the "Write Document" page in areas which allow uploading. When this option has been clicked, the document is put on hold (not posted) until the file has been received. The User will be prompted whether they can perform FTP uploads from their browser. If so, then a temporary FTP-Upload directory is created on the web server, and the user is linked to this page. MixHost periodically checks this directory to see when the file has been received. Once received, the document is finally posted and the uploaded file is copied into the general download directory. This directory contains all downloadable files for the entire hub. Name clashes will result in the newer file being automatically renamed to ******01... If the upload is not received within a given period of time, InterMix email* will be automatically sent to the author, and the temporary upload directory will be deleted. The author's (held) message will be quoted. Once the upload has been received, the (held) message will be posted, and the author will receive a confirmation message via InterMix email*. * Note that "InterMix email" is not personal SMTP email. It is accessible only through an InterMix session. MixTextDoc - The Generic Message Document: The term "Document" is widely used in the world of InterMix. Documents may be of differing format and use, but the most common and basic type document is the Message. A "Message" document is of the MixTextDoc class, and may be referred to as a MixTextDoc Message. InterMix does not generally predefine document types, however MixTextDoc is defined for global compatibility. InterMix hubs cannot share documents without sharing forms as well. It is troublesome for a hub to be constantly fetching form definitions from remote hubs, just to provide document viewing, hence the need for a standardized document type, the MixTextDoc. Note that the form used to display a MixTextDoc may be different on all hubs, unlike an advanced "Recommender" document which requires the exact form for display. A standard MixTextDoc (HTML) form will ship with InterMix. This form may be modified for any hub. MixTextDoc is defined with the following fields. A form may omit any of these fields, but the underlying document data is to contain these vital fields: Status - "PRIVATE" only if message is private. This should be blank if public. From - User-MixID of the author Hub - Hub-MixID of the originating hub Title - Document title Date - Date and time of creation or last modification Area - Area-MixID of the home area of the document Area Name To - Comma Delimited list of User-MixIDs Text - A multi line block of text ContainsHtml - Boolean value of whether the "Text" contains HTML, which should be displayed in HTML format Document Operations: Documents may be viewed, rated and replied to by all authorized users. Documents may be deleted, booted, moved and copied by a moderator or sysop. A moderator, sysop or the author may add or delete keywords for a document. Moving a document places the document in a new area, and removes it from the old area. Booting a document moves the document to its superarea. The author of a public document may choose to delete it, whether or not there exist public replies. A thread operation (See Interface Docs) which attempts to reference a deleted document will show " (Deleted) " as the document's body. This logic also follows if a sysop or moderator has deleted a document. Private email may be deleted if none of the recipients have read the document. Deleting Documents: A document may be deleted by the author if the document is public or if it is private and has not been read by the addressee yet. Sysops and Moderators can always delete documents. Documents, are organized in a tree-like hierarchy. An original (non-reply) message is known as the root. The reply is known as the child. Replies may be nested to any level, and large and complex threads (trees) may arise. Deleting a document may or may not be a simple procedure. If a document has no children (a "leaf-node" doc), then it may be cleanly removed. This is known as a "physical" deletion. If a document does have children, then extra care must be taken. First, the document's references in the keyword index are deleted. This will ensure that no queries will return this doc. Next the document's contents (or message text) is deleted and replaced with a message-type document which states "This document has been deleted". In effect, we are removing the document from InterMix at large, but we are preserving it's position in the document hierarchy. This allows threads to maintain their architectural structure. This type of deletion is known as a "logical" deletion. After a "physical" deletion (of a leaf-node) has been performed, the document deletion system automatically checks the departed document's parent. If the parent has been "logically" deleted and has no remaining children, then it is "physically" deleted. This process is then applied to the grandparent, and so-on and so-forth. This algorithm ensures the structural integrity of document trees (threads), and at the same time efficiently cleans dilapidated structures. Copying Documents: Special consideration is given to the action of copying documents. When a document is copied, the physical document is shared between the multiple areas, but the document's home area remains the original area. A new keyword reference connects the document with the new area. The copy logic follows: 1. When copying a document, only add a reference to the exact area copied into. The document might not show in a superarea of the copied area. 2. Every message has its own home-path. A visual distinction is made depending on whether the current user-path (area path) completely coincides with part or all of the message home-path. If it does not, then we must be looking at a reference copy of the message. This definition works with both a lateral copy and a copy down into a sub area of the home. 3. For reference copies A) A delete or boot merely deletes that one reference keyword. B) A reply goes into the current area of the user. C) The document path (light blue) will not show (though the home area and path will be available in doc info). D) On the tree, the document shows in italics to indicate it is foreign. 4. If we are looking at the home copy of the document A) A delete will delete all references to the message, including copies everywhere -- the home moderator owns the document -- can modify, delete etc even if it has been copied to some other area not owned by that moderator --if there are replies, we have to handle the missing document in the thread. *** See "Interface" document for information on thread handling. B) A boot moves the home area to the area above the current area, deleting references to the current area and below as shown in the home-path from the document data. If the document has been copied down to a lower area from its original home area, then that reference is not known to the boot process and is not deleted. C) A reply to the document goes into the home area of the document D) If the document home path is longer than the current user (area) path, then the document path extension shows in light blue. E) On the tree, a non-italic type indicates a message belonging to the current area. 5. A document move command changes the home and the home path data in the document info. It also deletes all references from the old home path and adds all references from the new home path. Previous copies outside the old home path are not affected. Tracking Read/Unread status of documents: InterMix tracks the Read/Unread status of each recent document per registered user. This information may be used to filter out already-read documents from a document list. The Read/Unread flags are stored in binary buffers. They hold the Read/Unread status of the newest N number of documents, N depending of the size of the Read/Unread buffer which is set by the sysop. The buffer may be of sizes 1K (8,000 docs), 2K (16,000 docs), 4K (32,000 docs), 8K (64,000 docs), 16K (128,000 docs), 32K (250,000 docs). Each user's Read/Unread info includes this buffer plus Starting-Document and Ending-Document fields. Each document has a Doc-Number property, which is what the Read/Unread buffer relates to. The Doc-Number is a hub wide identifier, not area specific. If there are 10,000 messages on a hub, and the Read/Unread buffer size is 1K (8,000 docs), then a user's Read/Unread buffer would pertain to document numbers 2,000 .. 10,000. This buffer is read/modified/rewritten for each displayed document per registered user. Because these Read/Unread buffers may cause wasted disk space, the sysop has control of when these buffers are purged. This option will appear like - "Purge Read/Unread buffer after user has not logged in for N number of days". When purged, only this buffer is zapped, not the user's account. The user is required to turn on their read/unread tracking ability. The combined read/unread buffer space may grow excessively large. Therefor a user must request this option before having access to it. This will ensure that occasional novice users don't unnecessarily tax the server's storage. The Recommender: The Recommender is a unique, flexible and integrated document system. It is used for the cataloging, retrieval and sharing of specially designed databases. The databases are designed with the Recommender Database Designer. This product will be distributed independently from InterMix itself. Recommender databases are fully relational and contain intricate links to other types of Recommender databases. The Recommender's features will be illustrated through the following example: A "Movies" Recommender type is defined. The Movies data type contains the following fields: *Movies* Field Len Unique? Multiple? Xref? Misc. ---------------------------------------------------------------------------- Title 40 Y UNIQUE KEY Rating 5 [G;PG;PG-13;R] Year 4 Y Categories 15 Y Y [action;drama;horror;comedy...] Directors 20 Y Y Linked to *Directors* database Producers 20 Y Y Linked to *Producers* database Actors 20 Y Y Linked to *Actors* database Summary Memo Directors, Producers and Actors also have the following defined Recommender types: *Directors* Field Len Unique? Multiple? Xref? Misc. --------------------------------------------------------------------------- Name 20 Y UNIQUE KEY Birthdate 8 Movies 40 Y Y Linked to *Movies* database Awards 40 Y Bio Memo *Producers* Field Len Unique? Multiple? Xref? Misc. ---------------------------------------------------------------------------- Name 20 Y UNIQUE KEY Birthdate 8 Movies 40 Y Y Linked to *Movies* database Awards 40 Y Bio Memo *Actors* Field Len Unique? Multiple? Xref? Misc. ---------------------------------------------------------------------------- Name 20 Y UNIQUE KEY Birthdate 8 Movies 40 Y Y Linked to *Movies* database Awards 40 Y Bio Memo Directors, Producers and Actors types coincidentally share the same structure. Each type should have a "unique key" field which acts an identifier for cross-type Lookups and relations. Some fields may allow multiple entries, such as Category in the Movies type. Notice the "Linked" field properties of all types. These special "Linked" properties serve two purposes: 1. Cross-database links. This allows a link to a detail-type Recommender database. Nightmare on Elm Street lists Robert Englund as an actor. Because we maintain an actor database, we can easily click on "Robert Englund" to see details on that particular thespian. When viewing his "Actors" record, all of his movies are listed, and a simple mouse click will revert back to the Movies database with the selected movie data displayed. This type of link will even permit the Actor database to exist elsewhere on the network (Ver. 3.0). This will be facilitated through the GlobalMix protocol. 2. Smart 2-Way updates. When a specific movie is added to the Movies database, those listed actors, directors and producers will automatically have their respective Recommender databases updated. Nightmare on Elm Street will added to the "movies" field of each of the thee other databases if it does not already exist. Also if Robert Englund has no existing entry in the Actors database, then his entry will be automatically created and Nightmare will be added to the new actor entry. This type of automatically created record may leave required fields blank, but these fields may be supplied when manually modifying the record in the future. The Move-Director-Producer-Actor setup is only an example. This type of inter-database setup may be defined for any implementation the Recommender designer finds useful. Recommender imports and exports: Recommender databases may be exported and imported to and from other types of file formats. This allows easy utilization of existing databases. Recommender fields have the following properties: Name (must be unique (for this Recommender type only) ) Type (character, numeric, date, memo) Minimum entries (0 = not required) Maximum entries (for multiple entries) minimum numeric value (for numeric type) maximum numeric value (for numeric type) Default value Valid entries (for character type - a list of valid values, such as "G;PG; PG- 13;R") Linked database name Linked database field Unique (yes/no) Save entries as "general" keywords (yes/no) Save entries as "special" keyword type (name of special keyword type) Cross reference (yes/no) When a recommender field's "cross reference" property is "yes", then the displayed field becomes a link. Clicking on this link will produce a list of same-type documents with that field in common. In our example, clicking on "Robert Englund" in the Nightmare record will produce a list of movies in which Englund appears. Any item in this list may then be clicked on in turn. The "cross reference" data is stored and recalled as keywords in the query engine tables. The Keyword Type being the Recommender name+field name, and the Keyword Description being the data. Using our example, this would equate to "MoviesActor" and "Robert Englund." "Robert Englund" is also saved as a "General" keyword, so a system wide search will find him as well. A search may also be applied to all fields with a cross reference property. A search form will appear the same as the Recommender input form. Additionally the form will contain the radio buttons "All of these" and "Any of these". Native HTML code may be entered into Recommender fields on entry. When this Recommender item is later displayed, the interpreted HTML results are displayed, not the native HTML instructions. For example, an image may be imbedded in a Recommender field by include the following type of text: This idea may also be applied, for example, to formatting text and providing URL links. Recommender Extentions: A Recommender Extension is a Recommender type which inherits another Recommender type's database design and display forms. In addition to these attributes, an extension adds fields, input and display sub-forms. These sub-forms are blocks of HTML code which accept input and display output of the new extended fields. The sub-forms are displayed within the parent's form. The position of the sub-form is determined by a special "" tag which appears in the parent's HTML form. Recommender Organization: Recommender types are separated into different InterMix Areas. When an area's primary document type is "Movies", then this area is said to be a "Recommender Movies Area". In our example, the area hierarchy would appear like: All Areas ... Cinema Movies Actors Directors Producers Each Recommender type is uniquely assigned to an area (as the primary form type). This is very similar to the simple message type (MixTextDoc) being assigned to a discussion forum. Recommender types have their own input and display forms. These provide page formatting, or methods in which display the individual types. In the HTML version, these are HTML pages that contain special tags which are replaced with real data at runtime. Document lists (or queries) return items which are identified by a list-name. In the case of messages, the list-name is the message's title. In the case of Recommender types, the list-name is the evaluation of an expression. For example, the Movie type's list-name expression may either be something simple like "Title" or it can be a complex expression such as "trim(Title) + ' (' + Year + ') ' + Rated". The latter expression would produce something like "Nightmare On Elm Street (1984) R". This expression is evaluated through a parser. The parser recognizes field names, the "+" symbol, literal strings encased in quotes, and the following string functions: trim(string), left(string,length), right(string,length) and substring(string,start,length). Nested expressions are valid, such as "substring(right(trim(Title),2),1,1)". This example extracts the second from last character in the Title field. In addition to the regular sort types, Recommender areas may be listed by three additional designer-defined sorts. As in the list-name expression defined above, the three sorts are defined as expressions. The following three expressions could be defined for the Movies type: 1. Title 2. Year+Title 3. Rated+Title Although each of these three sorts may seem rather pointless on a full movie list, they would be much more meaningful when applying a filter to the query, such as "Al Pacino". Recommender Form Features: Recommender fields my be either entered into the Recommender Database Designer or an alternative field-importing method may be used. The later idea is implemented by the "Examine Recommender Form" option within the Recommender Database Designer. This features scans an HTML page and looks for all input fields (text, multi-line text, check boxes, radio buttons). Each field is then created with the appropriate length in the designated Recommender type. This feature only adds fields to an existing type. It does not delete existing fields from a type when the pre-existing fields do not appear in an examined form. Recommender Reply Forwarding: The Recommender features a special reply forwarding feature. This is an option which sends private InterMix email to the "Item Owner" of a Recommender entry. The body of this message is the contents of the reply. If the owner responds in turn to this message, the message will be sent to the author of the reply, not to the public area from which the reply was originally generated. Ratings: Only documents may be rated. Non-anonymous users have the ability to rate and re-rate documents. Two user rating types exist: An Interest rating and an Approval rating. Every rating is remembered by InterMix, and when a user acts to rate the a document a second time, the old rating values are replaced by the new values. Each document tracks it's own average Interest, average Approval, Controversy and Value. Controversy and Value are composite ratings calculated from user ratings. The Interest rating ranges in value from 0 .. 4. The Approval rating ranges in value from -3 .. +3. The Value is based on Interest & Approval and has a range of -916 .. 916 Million (5 base-62 digits). The Controversy is based on the standard deviation of approval ratings and has a range of 0..6. Queries may return documents sorted in the order of any of the four rating types. Queries may also sort on other fields as well. HTML Page Customization: The appearance of each InterMix area may be customized by allowing the sysop to specify an HTML file as a page header and an HTML file as a page footer. These headers and footers can contain miscellaneous links, graphics, Java applets, links to other InterMix Hubs, advertisements or anything else in HTML format. For example, the "IBM" area can have a different header and footer than the "Apple" area. An area's custom header/footer automatically propagates into subareas. The outward-most area is the Homepage. By default, all areas inherit the header/footer from the Homepage of the hub. Only the Homepage has a second inner layer of custom header/footers. These two sections are sandwiched between the top/bottom header/footer and the Homepage contents. This is a convenient place to include links to other hubs. Inbox: The Inbox button is available on the Homepage of the user who has logged in. The Inbox is more of an Interface specific feature, and it will be detailed more in the interface specifications. There are, however, a few important issues which should be covered here. The Inbox area is where registered users can receive both public and private InterMix documents which are addressed to them. References to Inbox documents are contained in a separate data table. The read/unread status of each Inbox document is tracked in this file, regardless of whether the user's general read/unread buffer is active or not. Each user starts with one general Inbox category, but they may define multiple categories for moving and automatic sorting of incoming messages. Messages may be automatically categorized based on the public/private status, the originating hub, the originating area and the author. Three form controls will appear on the Inbox page: A checkbox for "unread only" and radio buttons for "List new first" and "List old first". A form button will be used to regenerate the page. Outbox: The Outbox button is available on the Homepage of registered users who have logged in. There is no real outbox in the sense that it stores messages (documents) not yet sent. The Outbox is the place where all messages composed by a user are listed. Like the Inbox, the outbox may also contain categories defined by the user. The Outbox allows users to select a document, read it, and possibly delete it. Two form controls will appear on the Outbox page: Radio buttons for "List new first" and "List old first". A form button will be used to regenerate the page. What's Hot: What's Hot is a feature which applies to both areas and threads. A What's Hot button appears on the Homepage as well as for each InterMix area. What's Hot via Homepage: This page lists the most active areas. The number of areas listed depends on a sysop setting. Each listed area may be clicked to generate a document list. What's Hot via area: This type of page lists the most active threads in an area. Threads are identified by documents' root message properties. When a message is replied to and the author changes the Subject of the new message, that new messages becomes a new root. The number of hot threads listed depends on a sysop setting. Hot threads are calculated for every area subarea and superarea. For example, a thread may appear in the What's Hot list of Ford, Domestic makes, Cars and All Areas. Another hot "Ford" thread may be contained in "Ford" only. Daily Maintenance Thread: The Daily Maintenance Thread performs many operations. It is automatically kicked off once per day. The time of day depends on a sysop setting, preferably at a low traffic time. This thread sequentially performs the following operations: Archive Messages: Messages are either in current or archived status. Archived messages (documents) have the same visibility and accessibility as current messages. This status is only used when a "date range" is imposed on a query. The sysop controls the duration of messages' "current" status. This current/archived status is tracked though document keywords. When a document is created, a "current" keyword is automatically added. The "Archive" function of the Daily Maintenance Thread looks for current messages which have expired. When found, the message's "current" keyword is deleted and an "archived" keyword is added. When sorting documents by Date, an exact date range may be given. When not sorting by date, the date range may be set to "archived", "current" or "all". Calculate Top10%, Top1/3, Bottom10% for each area: Each document contains four types of ratings: average interest, average approval, controversy and value. A range may be imposed on each of these properties when activating a query. These ranges be one the following: Top 10%, Top 1/3, Bottom 10% or All. Each time a document is rated, its four new rating properties are checked against its area's top 10%, top 1/3 and Bottom 10% levels. If the document falls into or falls out of any of these ranges, keywords are either added or removed to reflect the changes. Each area's top 10%, top 1/3 and bottom 10% levels are recalculated daily for each of the four rating types. This is the job of the Daily Maintenance Thread. Calculate Hot Areas: Each time a new document is written to an area, the area's current and total "hot area" counters are incremented. There are seven of these counters, one for the current period and six for recent periods. The length of this period is under control of the sysop, typically a day. The Area table contains an index on the "total hot document" counter. The top few are selected as the "hot areas". Periodic maintenance must be performed on "hot area" counters. This is one of the jobs of the Daily Maintenance Thread. This maintenance is performed once every N number of days (sysop setting). The oldest counter is rotated out, the current period's counter is reset to zero and the total is recalculated. Calculate Hot Threads for each area: "What's Hot" mechanics pertaining to threads is very similar to the mechanics of tracking "hot areas". One difference is that the "hot thread counters" exist in a different file, although this is shielded from all client and interface classes. Each time a reply is written, the thread's "hot counters" are incremented for the area and all superareas in which the document exists. The periodic "hot thread" maintenance operates in much the same manner as the "hot area" maintenance, except that inactive threads (zero totals) are deleted from the "hot thread" file. Purge read/unread buffers: The sizable read/unread buffers of registered users may be purged after the user has not logged in for a specified number of days. The sysop has control over this time period. The Daily Maintenance Thread kicks off this process which deletes old buffers. These buffers are also automatically deleted when the buffer has not been updated for a long time and the most current window does not intersect the old buffer's window. ------------------------------------------------------------------------------------------------------------------------------------------- 2. The InterMix Data Engine - MixEngine The InterMix Data Engine, or the MixEngine class, is a non-visual independent entity which is called from all of the Interface classes. MixEngine methods accept and return KeyValueBlocks. All parameters and return values are packed into single KeyValueBlocks. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MixItem Class One of the most basic elements of the InterMix data model is the concept of the Item, or the MixItem class. The MixItem class is the base class, and there are no direct instances of it. The subclasses are directly used, and they are as follows: MixItem (base class - not directly used) MixHub (base class - not directly used) MixLocalHub MixArea MixUser (base class - not directly used) MixLocalUser MixDocument (base class - not directly used) MixTextDoc MixRecommenderDoc MixHelperDoc MixForm The MixID field is used to link the following MixItem objects: MixLocalHub is linked to MixLocalUser as the local hub's sysop MixArea is linked to a MixHub - usually MixLocalHub, but can be a remote hub if mirroring the area (Ver. 3.0) MixArea is linked to MixForm as the area's primary input/output form MixArea is linked to MixForm as the area's response input/output form MixArea is linked to MixArea as the parent area MixArea is linked to MixLocalUser as the area's Moderator MixLocalUser is linked to MixLocalHub MixDocument is linked to MixUser as the author/creator MixDocument is linked to MixUser as the addressee (0,1 or more) MixDocument is linked to MixForm as the document's display method MixDocument is linked to MixHub as the document's hub-of-origin MixDocument is linked to MixArea as the document's home area ** When "X" is linked to "Y", item "X" contains a reference to item "Y" through a MixID field. Each MixItem element is assigned a 120 bit (15 byte) alpha ID, the "MixID" field, which is assumed to be universally unique. This ID is base 62 - digits = ASCII 0..9,A..Z,a..z. The first six bytes represent the time the item was created, in number of 1/20th seconds since midnight, January 1, 1970. This gives a range of 90 years. The second set of nine bytes represent a random number between 0 and .135E+17. Together the high and low order of the 15 character id represents what is assumed to be a universally unique identifier across all installations of InterMix. Notes: After 90 years, the five-digit base-62 date runs out of possibilities, so it flips back to zero. This does not effect InterMix's logic or operation in any way. If the system date is prior to 1970 when creating a MixID, the date used will be a random number. The MixTextDoc and MixRecommenderDoc classes are very similar. Both MixTextDoc and MixRecommenderDoc are basically the same by definition. They are both displayable documents with input methods. They both get their input and display formats from a MixForm object. The only basic difference is that MixTextDoc is a scaled down version of MixRecommenderDoc. The body of a MixTextDoc document is a simple block of text with no special links, fields or sorts. MixRecommenderDoc documents can contain all of the above. A document may contain HTML code. InterMix may do one of two things with such a document. It may either send the contents to the remote browser as formatted HTML or as the document's contents actually appears (in plain text). A document's form which allows imbedded HTML to be input should include "(*) Format message with imbedded HTML codes" and "(*) Don't format message with imbedded HTML codes (the default)" radio buttons. MixHelperDoc is a document to be displayed by a helper application on the client's machine such as Word, Excel, Acrobat or a multimedia application. This document could even be an HTML page to be displayed by a new instance of the client's HTML browser. This is to be better defined at a later time. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - General Data Interface Methods - Version 1.0 Parameter Types: MixEngine methods accept parameters of different types. Listed in the next section are the public MixEngine methods. Listed below are the types and descriptions of the commonly listed parameters. MixID Char 15 The Base 62 0..9,a..z,A..Z universal InterMix item identifier KeyType Char 2 Keyword target type, "ID" for InterMix Document KeyDesc Char 10 Keyword description, such as "word","title","author" KeyText Char 25 The actual keyword text to be associated with the target (document) Interest Num 1 Interest rating - range 0..4 Approval Num 2 Approval rating - range -3..+3 Date A date value - like 05/05/95 InterestAvg Num 3.1 Average interest - range of 0.0 .. 4.0 ApprovalAvg Num 4.1 Average Approval- range of -3.0 .. 3.0 Controversy Num 3.1 Controversy - range of 0.0 .. 6.0 Value Num 10 Value - range -916 million .. 916 million Boolean TRUE or FALSE Success Boolean A boolean return value UserID Char 40 Id or handle or user - unique to the hub, not universally unique ------------------------------------------------------------------------------------------------------------------------------------------- KeyValueBlocks are used to send all MixEngine parameters and all return values. KeyValueBlocks are "arrays" of strings. Each element contains a key and a value In the following format: key=value Keys do not necessarily have to be unique. For example, a document-save method could receive a KeyValueBlock with 14 string elements like this: [ text=Hello World addressee=Roger addressee=Sandy addressee=Ronald some_number=1357 public=TRUE date=04/01/96 time=13:45:14 area MixID=abcd012345ABCD area desc=LA Collect keyword=world keyword=globe keyword=earth keyword=planet ] Key-Value Blocks: MixEngine both receives and returns KeyValueBlocks. The keys and values will be explained in each case. Text to the left of the "=" are Keys. Text to the right of the "=" are the descriptions of the Values. Key-Values appearing with a comma after the "Value" description imply multiple values are to be accepted per key. A line that simply states "(REPEAT)" means that the above list of Keys may occur again within the KeyValueBlock, presumably with different Values. Key-Value Blocks are used to pass parameters to MixEngine routines and receive return values from MixEngine routines. A great advantage of using this method is that multiple values may be returned. Likewise, a dynamic number of parameters may be passed to MixEngine routines. A Key-Value block is not an array. It is actually a contiguous string. It is much like a Windows .INI file, in that a key and value relationship exists for a varying number of items. Parameters are separated by a CR/LF pair, or an ASCII 13 + ASCII 10 (decimal). Six types of parameters are used. Formatting of the "Value" differ. Binary values are not used, that is ASCII values less than 32, except in the case of the "Binary" type. In any case, the "Value" directly follows the "=", no spaces. The "Value" types follow: String: Strings start at the first character following the "=". They terminate at the last character preceding the CR/LF. Strings are NOT enclosed in quotations. Strings, or memos, consisting of multiple lines are separated by the LF (ASCII 10) character. Numeric: Numerics are may be in the form of 999 or 999.999. The decimal (".") character denotes a real, or non-integer, value. Date: Dates are accepted as parameters as mm/dd/yy, mm/dd/yyyy, yymmdd or yyyymmdd. The preferred method is mm/dd/yy. For any of the above formats, the "-" character may be substituted for the "/" character. Dates are returned in the mm/dd/yy format. Dates of the double year, or "yy", format are assumed to be of epoch 1995, or of the 1900 century if greater than or equal to 95 and of the 2000 century if less than 95. Time: Time parameter values are of the hh:mm:ss, hh:mm, hh:mm:ssAM, hh:mm:ssPM, hh:mmAM or hh:mmPM format. The preferred method is hh:mm:ss. Time return values are of the hh:mm:ss format. Time zone and GMT are not relevant. Boolean (logical): Boolean, or Logical, values are accepted as parameters as either TRUE or FALSE, T or F, 1 or 0. Boolean values are return as either TRUE or FALSE. Binary: Binary data is not used in InterMix version 1.0, but it is a reserved data type. A Binary definition consists "*Binary" + a space + the Key name + an equal symbol + an alpha numeric number (length) + a comma (the delimiter) + a contiguous block of binary data. Binary fields are the only type that include the type reference ("*Binary") before the key. This is necessitated by the fact that a client may receive varying versions of KeyValueBlocks. For example, an older client may receive an unknown binary type from a newer host. If the client was unaware of the type being binary, then it would see the value definition as ending at the first ASCII 13+ASCII 10, causing erroneous results. All of the preceding types are used in the following Key-Value example of a radio show quotation: Contents End Of Line Type ----------------------------------------------------------------------- StationName=KFI CR LF String Location=Los Angeles CR LF String Band=AM CR LF String Freq=640 CR LF Numeric Host=John and Ken CR LF String Date=05/01/96 CR LF Date Time=16:15:05 CR LF Time Quote=I don't understand this LF String (multi line memo) Internet business. Can LF Somebody explain what email LF and the word wide web are? CR LF *Binary Sound=9,********* CR LF Binary (9 bytes of sound data) SoundFormat=AVI CR LF String Versions: When MixHost.exe starts a new session (assigns a Session-ID), it establishes the version of the client. The HTML client and engine will naturally be of the same version, because they are both contained in the same .exe file. The version information is only relevant to outside clients, such as a future plugin or MixHosts which communicate with each other. This version will be part of the client's state, and it need not be resent by the client for the duration of the session. This version number may be used by MixHost.exe to format output correctly and to understand the format of the input. The version number is not necessarily used by each method. It exists only to provide compatibility between different client and host versions. The version logic is to be used very sparingly, and it will be avoided whenever possible. The use of Key-Value blocks (see above) helps with many potential version difference problems. Key-Value blocks allow a free format of parameter passing, so the order, omissions, additions and sizes of parameters should not cause fundamental problems with differing versions. It is each version's responsibility to correctly interpret requests and correctly return results to clients of older versions. Care will be taken by Collective Communication to provide backward version compatibility when developing client applications. The first InterMix interface is of the HTML format. Version 2.0 will introduce public object methods which will allow for a InterMix specific clients to exist across the net. At the time of this writing, the client platform is as of yet unknown, although Java is the likely candidate. The InterMix client will run locally on a user's machine and make data requests to remote MixHosts. Third party clients may be written to interface with MixEngine when MixHost is introduced with public methods in later versions (2.0+). 3rd party Clients are not required to consider the version of the MixEngine when making a live connection. These clients should be written to the specifications of a particular version of MixEngine. If the client is incompatible with older engine versions, then the client should refuse the connection. The client should not be expected to handle every old version of the engine, although it may. The client should, however, automatically work with MixEngines of newer versions, as MixEngine is written to work with older clients. If the client receives return types it does not recognize, the MixEngine is of a newer version. The Client should ignore all return values it was not written to handle. Note that extra care may be taken by the 3rd party client to provide compatibility with older engine versions, but extra work is required to block features the older engines do not support. Public Methods: MixEngine also contains many non-public methods which handle the bulk of the work and are explicitly called from the public methods defined below. Items: (General methods which apply to all items) Item.Info // Retrieves an array of info-lists Parameter KeyValueBlock MixID=MixID, Return KeyValueBlock MixID=MixID Name=Name of the item - can be a Document title, user name, area name, hub name Parent=MixID of parent item - Null if no parent Grandparent=MixID of grandparent item - Null if no grandparent Root=MixID of root item Creation date=Date of creation Update date=Date of last change Has Child=TRUE or FALSE Owner=MixID of user who owns the document - sysop of hub, moderator of area, author/creator of a document InterestAvg=Average interest rating of the document ApprovalAvg=Average Approval rating of the document Controversy=Controversy rating Value=Calculated "Value" rating (REPEAT) .SetUserRating // Adds or Updates a rating Parameter KeyValueBlock User=MixID Item=MixID Approval=Approval Interest=Interest .GetUserRating // Retrieves ratings Parameter KeyValueBlock User=MixID Item=MixID Return KeyValueBlock Approval=Approval Interest=Interest .AddKeyword // Add keyword to item Parameter KeyValueBlock Item=MixID Type=KeyType Desc=KeyDesc Text=KeyText .DelKeyword // Del keyword from item Parameter KeyValueBlock Item=MixID Type=KeyType Desc=KeyDesc Text=KeyText .ListKeywords // Return item's keywords Parameter KeyValueBlock Item=MixID Return KeyValueBlock KeyType=Type of each keyword KeyDesc=Desc of each keyword KeyText=Text of each keyword (REPEAT) Item.GetChildren // Return direct children items Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID, Item.GetDescendants // Return all descendants Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID, Item.GetSiblings // Returns items with a common parent Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID, Item.GetParent // Returns parent (or blank if n/a) Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID Item.GetGrandparent // Returns grandparent (or blank if n/a) Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID Item.GetRoot // Returns root item Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID Item.GetFounder // Returns root of all roots Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID Item.GetAncestors // Returns list of ancestors back to the founder Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID, Item.GetRootDescendants // Returns list of all descendants of an item's root Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID, Item.GetFounderDescendants // Returns list of all descendants of an item's founder Parameter KeyValueBlock Item=MixID Return KeyValueBlock MixID=MixID, Queries: QueryEngine.New // New simple query - clears old Parameter KeyValueBlock Area=MixID QueryEngine.Query // Invoke query engine Parameter KeyValueBlock Results=# of results Return KeyValueBlock MixID=MixID, .Sort // Sets the sort property of the query Parameter KeyValueBlock Sort=Sort name Sort names: Date Interest Approval Controversy Value Alpha1 Alpha2 Alpha3 Direction=0 or 1 0=forward 1=backward *** If the .Sort method is not called, the area's default sort is used. *** .UnreadOnly // Sets query to return hits unread by user Parameter KeyValueBlock User=MixID .DateRange // Set date range Parameter KeyValueBlock Range=Description Descriptions: All Current Archived .InterestRange // Set interest range Parameter KeyValueBlock Range=Description Descriptions: All Top10% Top1/3 Bottom10% .ApprovalAvgRange // Set approval range Parameter KeyValueBlock Range=Description Descriptions: All Top10% Top1/3 Bottom10% .ControversyAvgRange // Set controversy range Parameter KeyValueBlock Range=Description Descriptions: All Top10% Top1/3 Bottom10% .ValueRange(low,high) // Set value range Parameter KeyValueBlock Range=Description Descriptions: All Top10% Top1/3 Bottom10% .AddKeyword // Add a keyword to the query Parameter KeyValueBlock Type=KeyType Desc=KeyDesc Text=KeyText .AddNotKeyword // Add a NOT keyword to the query Parameter KeyValueBlock Type=KeyType Desc=KeyDesc Text=KeyText .SetKeywordTypeAnd // Sets keyword list type to "All Ands" (No params or return) .SetKeywordTypeOr // Sets keyword list type to "All Ors" (No params or return) *** The previous two methods are mutually exclusive *** .AddRequiredKeyword // Adds a required keyword to the query Parameter KeyValueBlock Type=KeyType Desc=KeyDesc Text=KeyText Areas: Area.New // Create new area Parameter KeyValueBlock Parent=MixID Name=Char 40 Return KeyValueBlock MixID=MixID .Set // Set area properties Parameter KeyValueBlock Area=MixID Name=Name of area - for display Description=Multi line text description Moderator=User_MixID Lookup=Name of default lookup Public=Boolean - Whether area is public or private UserMayJoin=Boolean Readonly=Boolean UsersAddSubareas=Boolean AllowAttatchedFile=Boolean RequireAttatchedFile=Boolean InputForm=Form_MixID OutputForm=Form_MixID ReplyInputForm=Form_MixID ReplyOutputForm=Form_MixID .Get // Returns area properties Return KeyValueBlock Area=MixID Name=Name of area - for display Description=Multi line text description Moderator=User_MixID Lookup=Name of default lookup Public=Boolean - Whether area is public or private UserMayJoin=Boolean Readonly=Boolean UsersAddSubareas=Boolean AllowAttatchedFile=Boolean RequireAttatchedFile=Boolean InputMixForm=Form_MixID OutputMixForm=Form_MixID ReplyInputForm=Form_MixID ReplyOutputForm=Form_MixID .Move // Move an Area to a new parent Parameter KeyValueBlock Area=MixID NewParent=MixID .Delete // Delete area Parameter KeyValueBlock Area=MixID .JoinUser // Join local user to an area Parameter KeyValueBlock Area=MixID User=MixID .DropUser // Drop local user from an area Parameter KeyValueBlock Area=MixID User=MixID Documents: Document.New // New Document Parameter KeyValueBlock Author=MixID Area=MixID Parent=MixID Return KeyValueBlock Document=MixID .Set // Set message properties Parameter KeyValueBlock Document=MixID Title=Title of document Data=Text of document IsHTML=Boolean - TRUE if document contains HTML code Form=MixID of the document's form Addressee=MixID of addressee, Public=TRUE or FALSE Area=MixID of the document's area Date=Date Document was created or modified Attached=Filename of attached file .Get // Get message properties Return KeyValueBlock Document=MixID Title=Title of document Data=Text of document IsHTML=Boolean - TRUE if document contains HTML code Form=MixID of the document's form Addressee=MixID of addressee, Public=TRUE or FALSE Area=MixID of the document's area Date=Date Document was created or modified Attached=Filename of attached file .Move // Move Doc to a new area Parameter KeyValueBlock Document=MixID Area=MixID .Copy // Copy Doc to new area Parameter KeyValueBlock Document=MixID Area=MixID .Delete // Delete Doc Parameter KeyValueBlock Document=MixID .SetUserViewed // Set if user has viewed document Parameter KeyValueBlock User=MixID Doc=MixID Viewed=Boolean .GetUserViewed // Chk if user has viewed document Parameter KeyValueBlock User=MixID Doc=MixID Return KeyValueBlock Viewed=Boolean Hubs: Hub.SetLocal(KeyValueBlock) // Set local hub's properties Parameter KeyValueBlock HubName=name of hub HubDescription=Description of hub Public=Boolean RequireLogin=Boolean (applies if Public=TRUE) DailyThreadTime=Time of day to launch daily maintenance thread Read/UnreadSize=1,2,4,8,16 or 32 (size of read/unread buffer in Kbytes) Read/UnreadWhenPurge=Number of days to allow non-login before purging buffer WhatsHotFrequency=Number of days between What's Hot rollover WhatsHotAreas=Top N number of hot areas to report WhatsHotThreads=Top N number of hot threads to report ArchiveWhen=N number of days before a document if archived .GetLocal:KeyValueBlock // Get local hub's properties Return KeyValueBlock HubName=name of hub HubDescription=Description of hub Public=Boolean RequireLogin=Boolean (applies if Public=TRUE) DailyThreadTime=Time of day to launch daily maintenance thread Read/UnreadSize=1,2,4,8,16 or 32 (size of read/unread buffer in Kbytes) Read/UnreadWhenPurge=Number of days to allow non-login before purging buffer WhatsHotFrequency=Number of days between What's Hot rollover WhatsHotAreas=Top N number of hot areas to report WhatsHotThreads=Top N number of hot threads to report ArchiveWhen=N number of days before a document if archived Users: User.New // Create new local user Parameter KeyValueBlock UserID=User-id (40 chars) Return KeyValueBlock MixID=MixID (blank if user not added because not unique) .Set // Set local user properties Parameter KeyValueBlock User=MixID First name=20 char max first name Last name=20 char max last name Email address=40 chars Profile=User's chosen profile text .Get // Get local user properties Parameter KeyValueBlock User=MixID Return KeyValueBlock UserID=User-id First name=20 char max first name Last name=20 char max last name Email address=40 chars Profile=User's chosen profile text .Delete // Deletes user record Parameter KeyValueBlock User=MixID Lookups: Lookup.Save // Save current lookup settings Parameter KeyValueBlock User=MixID (not used if public lookup) Area=MixID (not used if public lookup) Name=Description of lookup (30 chars) Lookup.Load // Load lookup Parameter KeyValueBlock User=MixID (not used if public lookup) Area=MixID (not used if public lookup) Name=Description of lookup (used only for public Lookups) Visit Lists: VisitList.Set // Save a visit list Parameter KeyValueBlock User=MixID (not used if public visit list) Name=Description of the visit list (30 chars) ---------------- Repeat after here -------------- Area=MixID Lookup=Name of lookup (30 chars) Maximum=Maximum number of documents (REPEAT) VisitList.Get // Retrieve a visit list Parameter KeyValueBlock User=MixID (not used if public visit list) Name=Description of the visit list (30 chars) Return KeyValueBlock Area=MixID Lookup=Name of lookup (30 chars) Maximum=Maximum number of documents (REPEAT) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - QueryEngine Class The most complex element of MixEngine is the Query Engine, or the QueryEngine class. The query engine is passed a number of parameters and returns a list of results. This (limited) list is actually a simple list of MixID identifiers. Subsequent calls to QueryEngine may be submitted until the Query results are exhausted. The parameters passed to QueryEngine are grouped in five different classifications - Sort, Ranges, Keywords, Special Case and Area. Sorting: The returned values are may be sorted (forward or reverse) by the following properties: Date Interest Approval Controversy Value Alpha1 (Recommender types) Alpha2 (Recommender types) Alpha3 (Recommender types) Date..Alpha3 are handled by the same search algorithm and the latter two each have separate query methods. Topic is based on a Date query, but hits are returned in groups like-topics. Best-Keyword-Match is based on the strength of matches containing one to every element of a keyword string - for example: "Delphi CGI Components". Ranges: A number of ranges may be defined for each query as well: Date Interest Approval Controversy Value Alpha1 (Recommender types) - separate lookup file Alpha2 (Recommender types) - separate lookup file Alpha3 (Recommender types) - separate lookup file Keywords: Keywords may be included with every query. Complex-logic operations may be used with any of the keywords. Keywords may be associated by AND, OR and NOT operators. For example: Rocky AND Bullwinkle Rocky OR Bullwinkle Rocky AND NOT Bullwinkle Special Filters: Unread messages only Root messages only Exclude messages from subareas Include messages only from subareas Addressee: Anyone "All" (no addressee) You Moderator Other Sender: Anyone You Moderator Other Area: The area also part of the query. Areas exist in tree-structure hierarchy. For example: AAA BBB CCC DDD EEE FFF GGG HHH III A document in area GGG belongs to GGG, FFF, EEE and AAA. A query with area EEE will return documents from EEE, FFF, GGG and HHH. QueryEngine Note *** With the exception of Unread-messages-only, Special-Filters and Area are accomplished through automatically adding keywords to the query request. The only required parameter in a query is the Area. A new query is initially setup through a call to the method: QueryEngineNew.(Area) The Query engine is invoked by a call to QueryEngine.Query(Numer_of_results):Array_of_results Before the Query method is initially called, calls to the following methods may be optionally called to refine the query: .DateRange([All,Current,Archived]) .InterestRange([All,Top10%,Top1/3,Bottom10%]) .ApprovalRange([All,Top10%,Top1/3,Bottom10%]) .ControversyRange([All,Top10%,Top1/3,Bottom10%]) .ValueRange([All,Top10%,Top1/3,Bottom10%]) .AddKeywordAnd(Keyword_type,value) .AddKeywordOr(Keyword_type,value) .AddKeywordNot(Keyword_type,value) Special Filters are automatically created by calls to the .AddRequiredKeyword method. QueryEngine contains the following relevant fields: KeyHigh (static) KeyLow (static) KeyCurrent (changes) MessageCurrent Keyword searches are recursive and are group by logic type. Simple searches have one keyword requirement: Area All non-simple searches boil down to: Area AND (XXXX) Examples: "InterMix News" AND "Rocky" AND "Bullwinkle" "InterMix News" AND ("Rocky" OR "Bullwinkle") "InterMix News" AND NOT "Rocky" AND RootMessage The top layer of keywords is ALWAYS an AND list. OR lists are considered nested, and the OR group result is always evaluated as an AND value in the higher level. ------------------------------------------------------------------------------------------------------------------------------------------- and returnvrInjfbl^zYU Q M{ I*$ ( { wPs`okg"c *_3*[f-W-S5Oy6K* y6=<wB<sToTk^g^c"c_'c[nWnSNOWK* W wsokg'cΩ_ک[WSѵOK* wsOofkϻgݻc_[WSOK* Zw]sNowkgc_[@WYSOK* wrsokEgc_[BWPSOxK* xwsok8gc_X[dW S)OlK* lrwso!k!g$c$_%[%W(S)O+K* ++w.s.o1k+1gp3c3^ 5Z5UCQCLCH$ CJwJsQZoYZkWeghecؔ_ZVɖRNJ wso-kcglcȜ_[WSiOvL 000-kcglcȜ_[Jh8p @ x0000000 0Jh8p @ x 0)0H0c0m0000Jh8p @ x00000%0c00Jh8p @ x000 0090X0w0Jh8p @ xw00000 00"0Jh8p @ x"00L0a00000 0Jh8p @ x 10S0g0|00000Jh8p @ x0000000 0Jh8p @ x /0;0G0R0^0l0y0{0Jh8p @ x{00000000Jh8p @ x0000 000,0Jh8p @ x,.0E0G0v00000Jh8p @ x00j0l0x0z000Jh8p @ x00O 0Q 0 0 0 0 0Jh8p @ x 0 0 0K 0U 0y 0{ 0 0Jh8p @ x 0A 0C 0 0 0 0 00Jh8p @ x!0#0L0N0P0^0`00Jh8p @ x&0(000]0_0a00Jh8p @ x000n0p0000Jh8p @ x0L0N000000Jh8p @ x 0$ 0] 0 0 0 0!0G!0Jh8p @ xG!u!0!0!0!0!0!0"0L"0Jh8p @ xL""0"0"0"0%0%0(0(0Jh8p @ x(*0 *0"*01*03*0*0+0W+0Jh8p @ xW+Y+0+0+0b-0d-0f-0-0-0Jh8p @ x-}20204040_40505050Jh8p @ x5505050'60:60O60e60w60Jh8p @ xw6y60;=0==0A0A03B05B0UB0Jh8p @ xUBB0B0C0YC0C0D0cD0D0Jh8p @ xDD0PE0{E0E0%F0{F0F0F0Jh8p @ xFF05H0\J0 K0K0N0N0Q0Jh8p @ xQQ0%S0'S0T0T0T0T0T0Jh8p @ xTX0X0Z0Z0[0[0C]0E]0Jh8p @ xE]]0]0^0^0^0^0^0^0Jh8p @ x^`0`0c0c0d0d0h0h0Jh8p @ xhi0i0Yk0[k0n0n0n0n0Jh8p @ xnn0o0o0o0o0gp0p0p0Jh8p @ xpp0p07q09q0q0q0 r0r0Jh8p @ xr6r08r0r0r0]s0_s0as0s0Jh8p @ xss0s0u0v0 v0v0v0w0Jh8p @ xww0yx0{x0y0y0y0Ay0Wy0Jh8p @ xWyny0y0y0y0y0z0z0"{0Jh8p @ x"{{0{0{0{0|0b|0v|0|0Jh8p @ x||0|0|0R}0c}0e}0}0}0Jh8p @ x}~05~07~09~0~0~0~00Jh8p @ x00U0o000000Jh8p @ x3050700020z0|00Jh8p @ x0ρ000B0r0t0Z0Jh8p @ xZ\000U0W0<0>070Jh8p @ x790J0L0N0U0W000Jh8p @ x+0-0ʋ0̋0f0h0z0|0Jh8p @ x|~00000;0_00Jh8p @ x0ǐ00080:0<0n0Jh8p @ xnp00000000Jh8p @ x0ד0ٓ00000q0Jh8p @ xqs00000K0M00Jh8p @ x 0 000W0Y000Jh8p @ x00000000Jh8p @ x000ˡ000"0A0Jh8p @ xAZ00Ƣ0آ00>0@0n0Jh8p @ xnp0000)0+00Ȧ0Jh8p @ xȦ0%0Z00ħ000#0Jh8p @ x#A0v0000ʩ0̩0Ω0Jh8p @ xΩܩ0ީ01030?0R0i0k0Jh8p @ xkϪ0Ѫ000:0a0c00Jh8p @ x000 0 0000Jh8p @ x+0L0e000000Jh8p @ xz0|0?0A00 0m0o0Jh8p @ xo͵0ϵ0ѵ000K0M0O0Jh8p @ xOh0j040˻0ͻ0ϻ0ۻ0ݻ0Jh8p @ xݻL0N0ܾ0޾00000Jh8p @ x00000000Jh8p @ x00-06080000Jh8p @ x00000000Jh8p @ x0o0q000I0K0M0Jh8p @ xMz0|0000000Jh8p @ x00=0U00000Jh8p @ x00000000Jh8p @ x00000000Jh8p @ x0x0z0_0a0d0f0>0Jh8p @ x>@0B0W0Y00000Jh8p @ x00000000Jh8p @ x 0|0000000Jh8p @ x00000n0p0r0Jh8p @ xr00 0"0q0s000Jh8p @ x0 0Y0000K00Jh8p @ x020E0G0I0000Jh8p @ x0'0a0r00000Jh8p @ x00-0{0000/0Jh8p @ x/B0D0F0P0~0000Jh8p @ xb00000 00g0Jh8p @ xgi000000X0Z0Jh8p @ xZ0000C0o000Jh8p @ x00.0?0l0000Jh8p @ x00000000Jh8p @ xu0w0000000Jh8p @ x00000000Jh8p @ x00 0 0 0 07090Jh8p @ x9C0R0e0g0000;0Jh8p @ x;=000000V0X0Jh8p @ xXb0d0Q0S0000 0Jh8p @ x  0'0)000f0h0j0Jh8p @ xjl0t0v000000Jh8p @ x0000i 0k 0 !0!0Jh8p @ x!!0!0 !0!0!0n"0p"0$0Jh8p @ x$$0$0$0$0%0%0%0%0Jh8p @ x%<&0&0'0s'0u'0'09(0;(0Jh8p @ x;((0(0(0(0)0)0*0*0Jh8p @ x*+0+0+0+0+0+0i-0k-0Jh8p @ xk-.0.0.0.0/0/0Q00S00Jh8p @ xS0 1010-10/101020~2020Jh8p @ x220n30p3030304040 50Jh8p @ x 550506060>60h60w6060Jh8p @ x66060606070!70+70-70Jh8p @ x-7m70o707080e80808090Jh8p @ x9?90w909090=:0{:0:0:0Jh8p @ x:H;0;00<0<0=0=0>0/>0Jh8p @ x/>1>0=@0?@0@0A0A0A0A0Jh8p @ xAA0%C0'C0C0C0C0C0C0Jh8p @ xCC0D0D0D0D01E0E0E0Jh8p @ xEE0 F0F0fF0F0F0G0Jh8p @ xGTG0VG0rG0G0G0G0G0H0Jh8p @ xHH0H0I0I0 J0J0/J0BJ0Jh8p @ xBJPJ0`J0pJ0J0J0J0J0J0Jh8p @ xJJ0J0J0K0L0L0N0N0Jh8p @ xN P0P0Q0Q0Q0Q0DS0FS0Jh8p @ xFS,T0.T0T0T0W0W0X0X0Jh8p @ xX#X0lX0X0X0X0X0Y0-Y0Jh8p @ x-YKY0Y0Y0Y0Y0*Z0KZ0MZ0Jh8p @ xMZOZ0QZ0\Z0^Z0]0]0>_0@_0Jh8p @ x@_Ea0Ga0Se0Ue0We0he0je0e0Jh8p @ xef04f06f0lf0f0f0f0f0Jh8p @ xfg0Hg0g0g0g0g0 h0[h0Jh8p @ x[h}h0h0h0i04i0Ai0Ci0ui0Jh8p @ xuii0i0i0i0i0i0j0#j0Jh8p @ x#j2j0Aj0Yj0oj0j0j0j0j0Jh8p @ xjj0j0k0k0k0@k0[k0kk0Jh8p @ xkk|k0k0k0k0k0k0k0l0Jh8p @ xl2l0Sl0tl0l0l0l0l0l0Jh8p @ xll0m0m0Em0`m0om0m0m0Jh8p @ xmm0m0m0n0n0+n0-n0gn0Jh8p @ xgnn0n0n0n0n0n0o0(o0Jh8p @ x(o@o0Po0Ro0{o0o0o0o0o0Jh8p @ xoo0p0p0-p0Ep0Up0Wp0p0Jh8p @ xpp0p0p0p0p0Gq0bq0qq0Jh8p @ xqqq0q0q0q0r0r05r0Fr0Jh8p @ xFrHr0Jr0Tr0Vr0r0r0r0r0Jh8p @ xrr0s0s04s0Fs0Hs0~s0s0Jh8p @ xss0s0s0s0s0s0t0t0Jh8p @ xtt0,t0Yt0t0t0t0u0u0Jh8p @ xuu0>u0Yu0ou0u0u0u0u0Jh8p @ xuu0u0u0 v0v0'v04v0Av0Jh8p @ xAvQv0Sv0v0v0v0v0v0v0Jh8p @ xvv0v0v02w0Mw0cw0vw0w0Jh8p @ xww0w0w0w0w0w0 x0 x0Jh8p @ x x*x07x0Dx0Tx0Vx0x0x0x0Jh8p @ xxx0x0x0y0.y0?y0Py0ay0Jh8p @ xaycy0y0y0y0z0z0z0Wz0Jh8p @ xWzYz0z0z0z0z0z0z0z0Jh8p @ xzz0z0{09{0J{0[{0s{0{0Jh8p @ x{{0{0{0{0{0'|0@|0b|0Jh8p @ xb||0|0|0|0}0%}0>}0X}0Jh8p @ xX}v}0}0}0}0}0}0 ~09~0Jh8p @ x9~R~0t~0~0~0~0~0070Jh8p @ x7S0p000000 0Jh8p @ x 0!0C0_0n0r000Jh8p @ xπ0ހ00000?0N0P0Jh8p @ xPR0^0`0000Á0ԁ0Jh8p @ xԁ000-0I0\0x00Jh8p @ x˂000,0R0000Jh8p @ xԃ000060o000Jh8p @ xЄ00%0L0N0y000Jh8p @ x00000'0)0J0Jh8p @ xJf0y0{00҆0000Jh8p @ x0?0[0j0x0000Jh8p @ x000 0F0Y00Έ0Jh8p @ xΈ0k0000[0]00Jh8p @ x0ʊ00050x0ċ00Jh8p @ xV00ƌ000 000Jh8p @ x?0Z0x00͍0ύ000Jh8p @ x'0M0q000000Jh8p @ x 0$0:0`000Ə0ȏ0Jh8p @ xȏ0 000(0*0`0{0Jh8p @ x{0ѐ000"0=0h00Jh8p @ xё0ӑ0Ց0000/0_0Jh8p @ x_0ɒ0ْ00(06080i0Jh8p @ xi0000070`0n0Jh8p @ xnp0s0֔0ؔ00000Jh8p @ xǖ0ɖ0"0$0*040>0K0Jh8p @ xKR0n0000000Jh8p @ x00B0D0J0T0^0k0Jh8p @ xkr00ؙ0 0 0000Jh8p @ xК0Қ00000+0-0Jh8p @ x-N0o0q0000˛00Jh8p @ x0 00&0(040?0G0Jh8p @ xGU0_0a0c0j0l0Ɯ0Ȝ0Jh8p @ xȜ͜0Ԝ0ۜ000000Jh8p @ x00K0M00000Jh8p @ xC0E0Ϟ0ў0002000Jh8p @ xӟ0010c0000ؠ0Jh8p @ xؠ00U0W0Y0000Jh8p @ xʡ0ۡ0ݡ000Q0S00Jh8p @ x0Ƣ00*0,0У0ң0_0Jh8p @ x_a0c0e0g0i0k0m0o0Jh8p @ xoq0s0u0v0x0k0m0o0Jh8p @ xf=/2$898(@ x00[0]00Jh8p @ xTimes New Roman0Modern Arial00Jh8p @ x