Journal and Overlays

From OLPC
Revision as of 20:51, 31 May 2007 by Mcfletch (talk | contribs) (Initial upload of the workup for using the Journal and the AUFS together)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is the beginning of working up how to integrate File System Overlays 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)