summaryrefslogtreecommitdiff
path: root/blog/2021/07/04/meetings.mdwn
blob: 216010c4f5efc39b3ab0af1ed1825c6bc7e7b294 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
[[!meta title="Iteration planning: July 4–18"]]
[[!tag meeting]]

[[!toc levels=1]]

# Assessment of the iteration that has ended

[previous iteration]: /blog/2021/06/06/meeting

The goal of the [previous iteration][] was:

> Change the Obnam client to use async Rust to be more concurrent. The
> result doesn't need to make optimal use of all cores, but it needs
> to pass the test suite and needs to work.

This was not achieved, due to Lars being busy with changing jobs.
Overall, not a lot of things happened this iteration. This is not a
problem: Obnam is a hobby project, and is worked on when it's fun.
Obnam is not intended to be "feature complete" as quickly as possible.
It's meant to become a solid backup solution for the long term. Also,
it's meant to be fun.

# Discussion

Lars has accepted a new job and has some time before it starts, and
intends to do some work on Obnam. This iteration picks up where the
previous iteration started.

Lars has been doing some thinking about Obnam development strategy,
and feels that there are several features that affect the software
architecture deeply:

* security and safety
  - encryption of backed up data
  - replay attacks
  - handling of encryption keys
  - other threats
* performance
  - concurrency in client
  - caching of data chunks
  - handling huge amounts of data
  - handling huge numbers of files
  - event-driven operation over scanning the file system
* shared backup repository
  - supporting many clients on the server
  - sharing backed up data between clients

Lars concludes that it doesn't really make sense to work on all of
these at once. Instead, he will work on one aspect of one feature at a
time, over one or a few iterations. Currently that's concurrency in
the client.

# Goals

## Goal for 1.0 (not changed this iteration)

The goal for version 1.0 is for Obnam to be an utterly boring backup
solution for Linux command line users. It should just work, be
performant, secure, and well-documented.

It is not a goal for version 1.0 to have been ported to other
operating systems, but if there are volunteers to do that, and to
commit to supporting their port, ports will be welcome.

Other user interfaces is likely to happen only after 1.0.

The server component will support multiple clients in a way that
doesn’t let them see each other’s data. It is not a goal for clients
to be able to share data, even if the clients trust each other.

## Goal for the next few iterations (not changed for this iteration)

The goal for next few iterations is to have Obnam be performant. This
will include, at least, making the client use more concurrency so that
it can use more CPU cores to compute checksums for de-duplication.

## Goal for this iteration (same as last iteration)

Change the Obnam client to use async Rust to be more concurrent. The
result doesn't need to make optimal use of all cores, but it needs to
pass the test suite and needs to work.


# Commitments for this iteration

Lars intends to make a proof-of-concept prototype for using async Rust
in the client for chunking live data, and computing checksums for
chunks, using all the computing resources available. This will be part
of [[!issue 113]] (client is not async), but is too experimental to
estimate at this time.

In addition, Lars intends to work on [[!issue 111]] to document what
Obnam's subplot needs.


# Meeting participants

* Lars Wirzenius