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