[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Duplicity-talk] Developers: backend source re-organization
From: |
Peter Schuller |
Subject: |
[Duplicity-talk] Developers: backend source re-organization |
Date: |
Thu, 31 Jul 2008 21:53:09 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hello,
So I would like to re-organize the way backens are structured in the source.
Motivation:
(1) It just generally makes sense to not have them all in one giant module.
(2) Several times in submitting some patches I have felt that I've had
to "swallow my pride" and do ugly stuff as a result of it; e.g. creating
an instance method, or no method/function at all, just because I don't
want to clutter upp the surrounding backends module with junk related to
a specific backend.
(3) For further work on concurrent upload support (the beginnings of which
are in [1]) several changes relating to the backend interface would have
to be made (details are in previous posts to this ML a few months back),
so it would be nice to get such a re-organization done with.
I think Kenneth has indicated he want's to do something about the
backends too.
Before I do, since it's basically a bunch of boring mechanical work so
I might as well request objections first, here is an approximate plan:
Move the generic Backend interface into a "duplicity.backend"
module. Create a "duplicity.backends" module[2] whose sole purpose is to
contain individual modules for individual backends.
I specifically want to move things away from the "duplicity.backends"
module because I want individual modules to be able to import and use
the generic module containing the generic interface and some module
registration logic - but a submodule cannot import it's parent (except
by hacks involving deferred non-top-level imports) due to the module
loading mechanism in Python. So that stuff goes into
"duplicity.backend" instead.
Each backend would move into its own dedicated module which, upon load
time, would register it as an available module. If the module
determines that it cannot operate due to a missing dependancy, it
registers a dummy module which, when actually used, will explain that
this is the case.
As part of the initial changes, or after them, the various individual
modules would be given a slight polish to no longer do things like
randomly importing modules at some arbitrary location, trying instead
to do conditional importation/functionality checking in a more formal
explicity phase (this, aside from IMO being nice, also goes towards
making it easyer to make backends properly thread-safe).
So:
(1) Does anyone have objections to anything said above?
(2) Does anyone feel I should specify more detail before attempting anything,
even
if you may agree with what has been said?
(3) Is anyone aware of existing patches, or do people have their own patches
not yet public, that would massively conflict with the above? The problem
is that in terms of CVS version management it's going to cause problems
for any concurrent development.
Due to the concurrency problem mentioned in (3), I'd like to
co-ordinate with Kenneth once it's agree that it seems like a good
idea, such that once greenlight is given I can work up the patches and
get the committed fairly soon thereafer, to minimize problems for
other people doing any work on the code base.
[1] https://savannah.nongnu.org/patch/?6353
[2] Making it a "package", but I never understood the motivation behind
that distinction, and prefer to think of it as an hierarchy of modules.
--
/ Peter Schuller
PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org
pgp2ujJ1Pj6sZ.pgp
Description: PGP signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Duplicity-talk] Developers: backend source re-organization,
Peter Schuller <=