[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cross-platform backup tool Some updates about the current direction of r
From: |
EricZolf |
Subject: |
cross-platform backup tool Some updates about the current direction of rdiff-backup |
Date: |
Sun, 28 Nov 2021 07:37:05 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 |
Hi,
I wanted to give you all some news about what's currently happening, as
you might wonder why nothing is being released.
Well, we're in a major refactoring exercise to be prepared for future
endeavors. I want a much cleaner architecture which makes it easy to add
new features, and avoid issues (or easier to fix them :-P).
There are some majors aims with this refactoring:
1. have a clear API between client and server, with versions and clear
compatibility matrix between different versions of rdiff-backup
2. encapsulate the repository format so that changes can be done without
impacting the whole code (e.g. different compression algorithm)
3. avoid the use of global variables, especially modified all over the code
4. overall clarify the structure of rdiff-backup, add wherever possible
a plug-in concept
Currently all these points are not given, and the code has dependencies
all over the place, so that maintenance is a game with fire (and my
initial blind migration from Python 2 to 3 didn't make it better).
The target structure has been described at [1] resp. [2] (once merged).
In a few bullet points, the highlights:
1. there is a plug-in architecture for actions [3] on the left hand-side
(for the ones who've tried the alpha-version, they'll recognize the new
CLI's actions).
2. the locations don't have (yet?) a plug-in setup but they encapsulate
the client-server communication _and_ the format of the backup repository.
3. each action on the client side can communicate with one or more
locations (e.g. backup reads from ReadDir and writes to Repo).
4. it is then the role of the location to communicate with its "shadow"
hosted on the server side (server is a special action in this regard).
5. the client-server API is then defined solely by:
a. the communication between the locations and their shadows
b. the object types they exchange
c. the global variables exchanged between client and server (too many to
be completely avoided, this is definitely a sore point and a risk)
So, where do we stand?
The overall structure has been created, a lot of API calls have been
moved to the new structure (the actions don't anymore communicate
directly with the server), but there are still many objects
communicating directly which need to be rewritten.
And because I need to re-write the client-server API while making sure
that it remains compatible with v2.0.5, and also need to add new tests,
it takes quite a while. I'm therefor not releasing yet because each new
release means keeping the compatibility for also this new release.
Anyway, once the whole communication is nicely going through the
locations, I'll have to do some clean-up because the API doesn't have
currently much consistency as it comes from a bunch of different
classes, just merged into the locations. That'll probably mean a 2nd
complete reshuffling of the code.
The old API has been versioned 200, the new one is currently 201 (on
purpose not aligned with the rdiff-backup versions), so the plan is the
following:
* version 2.0.5 has been deemed talking version 200 of the API
* version 2.2 will talk 200 and 201, by default 200
* version 2.4 will talk 201 and 202, by default 201 (I'll probably keep
200 as well to avoid changing too many tests in this phase)
* etc...
* latest version 2.8 will speak the old version(s) and have a new
version, say 210, but speaking 20x by default
* then 3.0 will drop the compatibility and only speak 210 (or
equivalent), definitely deprecating the old cruft, which will again mean
a lot of changes, especially on the testing side (which currently relies
mostly on version 200), but avoiding any feature change.
* then we'll start a similar game with the format of the backup
repository, somewhere between version 3 and 4 of rdiff-backup
Regarding other foreseeable changes, we will have to drop Python 3.6
relatively soon, and add 3.10.
As for the timeline, no clue, I'm still hesitating on when to freeze the
API 201 and release version 2.2, but surely sometimes next year.
Stay tuned,
Eric
[1]
https://github.com/rdiff-backup/rdiff-backup/blob/ericzolf-target-architecture/docs/arch/rdiffbackup_architecture.svg
[2]
https://github.com/rdiff-backup/rdiff-backup/blob/master/docs/arch/rdiffbackup_architecture.svg
[3]
https://github.com/rdiff-backup/rdiff-backup/blob/master/docs/arch/plugins_actions.adoc
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- cross-platform backup tool Some updates about the current direction of rdiff-backup,
EricZolf <=