Journal and Overlays

This is the beginning of working up how to integrate Union File Systems and the Journal. Using AUFS-type overlays it should be possible to support both Sugar-specific and legacy applications in a fairly natural way as far as integrating into the Journal mechanism.

Journal Population (automated)

on start (pre-launch)

• install image
• opened file r/o image
• current r/w image

on individual file open

• hard link into r/o image
• file name choice (original + suffix if necessary)?
• on conflict choose overwrite or rename

on open journal (project space)

• load all files from journal record in r/o layer
• plus as for new image

on file save

• metadata entry optional (tags for journal)

on application close

• record referenced file uris
  • files loaded into space
• record underlying (real) filenames in journal for new/changed files
• does cut/copy and paste produce a "reference"?
• do not move or alter file on disk

Backup of Journal

on backup

• record backup uri/uuid for the file + local file
• record encryption key for file (encrypted w/ the uri)
• upload encrypted package with metadata and changed files
• record backup (tentative) flag (should have a signed return-receipt from the top-level backup server before we trust that it's really "safe")

on share

• if local, share file + uri + document key
• if not local, share uri + document key
• default no share
  • "class" share option (need to find your class)
• sign request to share for backup
• encrypt sharing certificate for target users if not public
• what about the underlying files?
  • do we want one uuid and key per file? yes
  • select which files to share rather than the whole environment
• journal entry is itself a sharable file
  • share referenced resources? (when we own them) question on share
  • what about derivative works? Does the original source need to sign off on sharing?
• publish sharing certificate via whatever means
  • email
  • direct share via IM
  • publish on server
    • personal log channels (tags)
  • references fields
  • pass to someone else to forward

comments

• references field in certificate
• normally text payload, but allow any content type
• share resource as normal

blog interfaces

• display public postings
• allow filter by tag and date
• comments inserted by web "user" into separate account with references fields
• private comments shared directly with user

backup upload

• needs to know who, how much,etc
• should only give to:
  • backup server (signed cert)
  • if desperate, someone who sees a backup server regularly
  • requires a mechanism to track connections

download requests

• signed sharing cert
• uuid of already shared (fail if not avail)
• public-log-view
• uuid needs to include account information

school server issues

• how to signal laptop that we are ready to go?
  • don't want 300 uploads at 08:00 and none at 08:01
  • especially as users will be starting working
  • do backup when we have local bandwidth spare (prefer, but get it done)
• how to prioritise uploads/downloads?
  • how urgent is your upload?
  • how much have you transferred already?
• how to serve files?
  • https server?
  • uploads as https file uploads?
• quotas need to be dynamic
  • on cache full no more accepted
  • who maintains on failure?
• "I have 25MB for backup, what do you want to store?"

global access mechanism

• where does the root server go to get the data for a request?
  • same place it went to put it in
  • the fact that one server is storing those passwords is an issue
• filter out those for whom it doesn't sharing certificates
• every machine should have their data backup account password
  • central server for "outside" access
  • (plus) every machine have access software for self-account

teacher's view

• that shared with the teacher
• if not public it's private
• comments to child are text notes shared with child
• marks and the like may or may not be shared
• default tag-set for each course
  • group for each course (needs automation)

no-backup/backup-until/backup-until-read-by

• voicemail, IM
  • what about abuse?
• server-level
  • allow for prioritisation in resource scarcity situations (upload bandwidth or space)
  • backup when possible, but drop first when full
• default in certain types to quick deletion or until-read
• take file size into account for strategy

Alternate Storage

• some simple way to suggest
  • diff-based storage
  • replacing storage
  • versioned storage
• plus file size hints
• plus timeout hints

Personal Importance Level

• prioritise in scarce resource situations
• automatically give precedence to last version of same resource within my uri space
  • (saved to same file as reference)
• references increase priority if not explicitly set

Journal Based File Open

• choose whole journal entry (namespace)
  • then choose file from it
• browse into entry to choose single file to import into new space
• browse journal to find old versions
• filter journal to find items (tag, type, text, etc)