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

[Tomeu Vizoso]

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?

Thanks,

Tomeu