Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/solidsnack/cloudsat


https://github.com/solidsnack/cloudsat

Last synced: about 1 month ago
JSON representation

Awesome Lists containing this project

README 

        
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.