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

[Kim Quirk]

I'm not seeing the use case that I *think* is the primary one:

1) Backup and restore from a disaster recovery perspective.
and the secondary that goes with that is:

2) Ability to restore to a new laptop (as in the child lost the laptop or it
died and they need to restore their work to a new laptop)

You don't need any browsing capability for this.

Kim



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?
>
> Thanks,
>
> Tomeu
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080422/bed40d0b/attachment.html>