[Box Backup-dev] Future work

[Chris Wilson]

Hi Ben,

> I'd prefer it if people choose the bits they wanted to do. I agree with 
> Martin; this is about doing stuff we want to do.

Well, I want Box to be successful and to meet people's needs, because that 
in turn will make Boxi successful and important, and make me rich and 
famous </dream>.

> The raidfile modifications are suitable, but not very "sexy" and may not 
> be to your taste. But it is highly self-contained. I think there's still 
> some advantage in having them. RAID hardware isn't well supported on the 
> *BSDs (slight issues such as not reporting disc failures!), raidframe is 
> annoying to set up. But perhaps most interestingly, with a bit of extra 
> work it would allow us to RAID the entire machine, not just the discs, 
> building resilient clusters of three servers.

I'm not sure about raidfile. I have a feeling that hardware and OS-level 
RAID is a better way to go in the long run, since it benefits applications 
other than Box. I don't use it myself, and I might feel that my time was 
better spent making OpenBSD's software raid better. But if there is a 
geenral consensus that raidfile is useful and worth doing, then I'll do 
it.

> On the other hand, we could really do with a nice GUI based front end, 
> so why not continue making Boxi wonderful?

I'd love to do that, but unless Box works well - really well - there's no 
point. The single most important feature for me, out of the proposals for 
0.20, would be snapshots, but there's no way I can do that myself, or that 
you would accept the resulting code if I tried.

> It would be useful if you wrote some notes about your idea GUI 
> integration features on the wiki before you leave. I would really like 
> to leave the daemon doing it's stuff, and the GUI just connecting over a 
> local socket to control it. Perhaps even making a brestored which 
> handles the actual talking to the server.

The problem I have with the separate process is the number of variables. 
There can be so many more reasons why bbackupd.exe won't start or won't 
talk to Boxi over the command socket, that it's very difficult for users 
to diagnose and fix the problem. My idea was to offer both options - a 
quick way to do a full backup and see the status, and a way to manage and 
control the background service over the command socket.

> Have you considered having multiple users sharing the same store when a 
> whole machine is being backed up?

Sorry, I'm not sure what you mean here. Is it multiple bbackupds (boxes) 
sharing a single account, or multiple users (of a single machine) having 
access to their own files on the remote store?

The former is something that I would like to see support for, along with 
multiple, selectable encryption keys per account, to allow users to use a 
Box store as a secure place to store and exchange files. The latter sounds 
like a potential security risk, but if I start getting requests from users 
to back up shared servers, I would consider it.

> I'm not sure whether to be amazed at your enthusiasm for Box Backup or 
> worried about your sanity when I hear you're considering doing lots of 
> coding for the project while traveling around the world.

I would worry for my sanity - everybody else does. Fortunately I found an 
employer where the other employees make me feel sane by comparison, so it 
doesn't bother me that much any more. :-)

> PS: Some replies to your notes on the wiki.

Thanks! Will look at them and get back to you.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |