 this could be fine.  However, on reconnect, the first thing is that complete upstream state of
 table is set on server version of table, so reconnecting user only sends its changes if upstream
 hasn't changed anything in that same record.
+
+
+SERIOUS UNFINISHED ISSUE:
+1. Non-admin user is a collab on a project
+2. They open and edit a file
+3. They have some offline changes
+4. They are removed from that project as collab before those changes are saved
+5. There will be changes (and updates to file_use) that are denied, with
+   the error "FATAL: user must be an admin".  The client will just keep
+   retrying those forever, until the client refreshes their browser.
+6. Solving this is pretty tricky, e.g., the file_use table would have to selectively
+   have entries removed from it.  This just isn't solved.  The cb_fatal below
+   is just a workaround to reduce the impact of this problem, while hopefully
+   not breaking things too badly.
 ###
 
 # if true, will log to the console a huge amount of info about every get/set

                if @_state == 'closed'
                    # already closed so ignore anything else.
                    cb?('closed')
                    cb = undefined
                    return

                if @_fatal
                    cb?('fatal')
                    cb = undefined
                    return


    _connect: (cb) =>
        dbg = @dbg("connect")
        dbg()
        if @_state == 'closed'
            cb?('closed')
            return
