Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
A message board for cloud communication. Types & Tables ============== A Message is a notification from some board member posted to a channel on the board. Messages may be in reply to other messages; the Thread type describes this relationship. The Message type as a Postgres table: uuid | timestamp | poster | chan | message ------+--------------------------+---------+---------+--------- uuid | timestamp with time zone | address | address | text The Thread type as a Postgres table: before | disposition | after --------+-------------+------- uuid | flag | uuid An Address is a simply an LDH domain name which may have an @ and a short "local component" in front of it. The Disposition flag is one of: Ignored Acknowledged Problem Info End and is a way to indicate how a reply relates to the history of a process spawned as a result of receiving the message. When a client connects, they register subscriptions and an address as a pre-requisite to sending messages. Their subscriptions form Registered records: nick | timestamp | chans ---------+--------------------------+----------- address | timestamp with time zone | [address] In the implementation, registrations are tied to a client connection by database connection metadata (in Postgres, this is procpid and backend_start from pg_stat_activity). Operations ========== We can imagine four kinds of "users" for the cloud message board: * Server bots receive messages, post replies and perform tasks. * Task bots post tasks, monitor replies and keep track of task status. * Admin bots observe overall error rates and throughput, monitor space usage and truncate tables. * Ad hoc bots connect to peform various analytics, not relevant to the operation of the board on a moment to moment basis but of interest to those maintaining the cloud. From the roles above, we can expect that: * SELECTs of a very general nature need to be performed from time to time. * Deleting older messages, threads and subscriptions is necessary; but is also completely formulaic. A couple stored procedures and a foreign key constraint linking messages to threads is probably enough; we don't expect general DELETEs to be performed at all and thus no bot needs permission to do them. * Some very specific SELECTs need to be performed over and over again. For example, checking if there is, in a thread, new messages that indicate completion or failure, new messages that indicate locks being taken and so forth. These will eventually become stored procedures. Data additions are very limited. There are no UPDATEs at all -- message/task cancellation is accomplished with a reply having Belay in the disposition column, for example; and subscription cancellations involve adding an additional row to the subscriptions table. The two input operations are, fundamentally: * Posting a reply or a new message. * Updating one's subscriptions. For a server bots, maybe we only allow replies; so after establishing a connection and registering a subscript, server bots need only two operations: * reply, to form a mesasge; * inbox, to get a VIEW of relevant messages to SELECT from. For task bots its useful to have a `post' function to kick off a thread and a one or many stored procedures for walking the thread to find things like all acknowledgments, all failed tasks, all incomplete tasks.