Synchronizing xs-0.3 and xo-??? --- backups

[Eben Eliason]

2008/4/22 Tomeu Vizoso <tomeu at tomeuvizoso.net>:
> 2008/4/22 Eben Eliason <eben.eliason at gmail.com>:
>
>
> > 2008/4/22 Tomeu Vizoso <tomeu at tomeuvizoso.net>:
>  >
>  > > 2008/4/22 Martin Langhoff <martin.langhoff at gmail.com>:
>  >  >
>  >  > > On Tue, Apr 22, 2008 at 10:18 PM, Ivan Krstić
>  >  >  >  <krstic at solarsail.hcs.harvard.edu> wrote:
>  >  >  >  >  My solution is the simplest design I could create that allows both
>  >  >  >  > emergency restore (laptop FS has been trashed, get everything back) and
>  >  >  >  > individual file restore and sharing via a web interface running on the XS,
>  >  >  >
>  >  >  >  Indeed, reading bug 4200 the purpose of the protocol becomes clearer.
>  >  >  >  What I don't understand completely is the drive behind retrieving the
>  >  >  >  files via a web interface. I'd think that the main requirement is that
>  >  >  >  the Journal can talk to it in a simple enough fashion -- perhaps it
>  >  >  >  was a shortcut to avoid complex work on the Journal?
>  >  >
>  >  >  Yes, having the journal activity browsing its own backup as well as
>  >  >  the public sections of the other children could be quite a bit of
>  >  >  work. A web app that allowed clicking on a link and having that entry
>  >  >  installed in the journal seemed much better in the short-medium term.
>  >
>  >  Well, let's not confuse these two use cases.  I think they are quite
>  >  different.  Use case (a) offers a child a way to individually recover
>  >  entries that they themselves created, but which have since been
>  >  deleted from their Journal.  Use case (b) offers a child a way to
>  >  browse a repository of work that other children have created, with the
>  >  ability to download, share, and modify those works.  I think (a)
>  >  deserves to be tied closely to the Journal UI, which serves as a
>  >  history of what a given child has done, and is likely the place one
>  >  already will be when discovering one wants something that has been
>  >  deleted.  Case (b) is much more appropriate as a web app, and for that
>  >  matter likely requires additional UI capabilities for determining what
>  >  is allowed to be presented in this manner....we don't want every
>  >  backed up entry to be publicly shared with the world.
>
>  Yes, the two use cases are very different and, given enough resources,
>  should be implemented separately.
>
>  As we have so many important things left to do, it has been suggested
>  that a child could mark one of the entries in its backup as public, so
>  other people can access it. In this way, the backup section of a kid
>  in the server would have the following functionalities:
>
>  - browse backed up entries,
>  - download one entry,
>  - mark one entry as public,
>  - mark it as accessible by other user of the school server.
>
>  Does it look like a bad compromise between functionality and cost?

It's not particularly terrible, but there are some serious drawbacks:

1. The recovered object, as a download from browse, will be treated as
a new entry, with new metadata and activity id.  The main purpose of
the restore in my mind is to allow one to recover something within the
historical context.
2. The child can only recover objects which they also felt comfortable
tagging as public.
3. Loss of the clear distinction of the Journal as the place for
managing ones files.  This is a philosophical issue, but I think it's
still valid.  Browse is about new discovery, and obtaining new things.
 The Journal is about history, and managing ones own things.

- Eben