Hello,
this is a quick note summarizing my recent thoughts about config
synchronization. I'd be grateful for any comments about them.
First of all, the problem: we want to [be able to optionally] use the same
config from different machines. The physical details (whether we share the
same file or store config on the network somewhere) don't matter, but there
are some design-level problems which do. I see two related ones:
- it should be possible to share only some options but not the others,
sharing all of them in particular is surely a bad idea (many options
differ between machines running different OSs, but even if you use
the same OS everywhere you don't want to use the same windows positions
and sizes because not all of them have the same display resolution)
- the user should decide which options are shared or not (for example,
if you have a LAN of identical (same OS, same display resolution)
machines, then you may want to indeed share all options without exception)
Next is my proposed solution. I assume you know how the current Profile
class works (in brief: folders inherit settings from their parent).
1. a new concept is introduced: config source. This may be a file,
an IMAP folder on some remote server or maybe something completely
different. It must implement a wxConfig interface subset needed by
Profile (reading/writing/enumerating the entries and groups), that's
all. Besides:
a) each config source has a name, "local" is a special one and is
always used by Mahogany: this is the ~/.M/config file or the
registry/file under Windows. Mahogany will also probably have some
special knowledge of "global" config source which will be used for
the options shared between all installations -- but "global" wouldn't
be always used, only if the user chose so. Another idea I didn't have
time to think about yet (not enough time spent on the beach :-) is to
have "defaults" config source which would provide the options default
values. I don't know if extracting this in a separate config source
(instead of keeping it as a fallback inside Profile itself) has any
other advantages except for being 100% logical.
b) each config source has a priority: this determines the order in which
they're used by Profile. "local" has priority 0 (highest, it is always
consulted first), "default" (or "global" if there is no "defaults") has
priority 1000 (nicer for the users than INT_MAX but same meaning).
c) users would be able to define their own config sources ("Unix" one for
all settings to be shared between all Unix machines, for example)
2. the local config would contain the list of all config sources to use.
Maybe we shouldn't put a priority in the config source itself but allow
the user to configure the order of the sources here -- this is more
flexible although, to be honest, I don't know why would anyone want to
use the different order for the sources on different machines. In any
case, the "local"/"defaults" source is always the first/last one in this
list and can't be changed
3. Profile implementation is going to change:
a) reading options will first use the "local" source, then the next one
and so on until "global" and falling back to "defaults", this is
simple.
b) writing options is more troublesome as we need to know which config
source are we writing them to. This is the worst problem I have right
now so I'd especially appreciate any help here. Here are the solutions
I see:
(i) each option has a "kind" which would be either "shareable" or
"local" and if the user changes a "local" option it is written to
"local" config source, if [s]he changes a "shareable" one, it is
written to "global" if it is being used
pro: simplicity from the user's point of view
con: not flexible enough, what if you want to share a normally
not shareable option (or vice versa)? no provision for custom
config sources
(ii) have different dialogs or (more logical, but maybe worse because
it would consume valuable space in an already horribly bloated
options dialog) add a "config source" combobox to the options
dialog which would allow to edit local/global/whatever config
source separately
pro: maximal flexibility
con: bad UI, need to implement "delete this option from config"
or you'd never be able to share an option after entering its
value once
(iii) something I didn't think of -- any ideas?
4. In addition to all this, we'd need some infrastructure:
a) IMAP-based config source implementation
b) import/export one config source to another (i.e. write all values from
the registry to an IMAP folder): this is especially important for
people who upgrade (including all of us :-). If we use (ii) from above,
there should be a possibility to export only some options, not all
c) bootstrap problem: if we don't use local config for anything at all,
we'd need to open an IMAP connection very early during startup process
which could require some extra work
d) we need some way of locking config during use (see below) and handling
this in the program
5. I don't address any (smart) synchronization concerns at all: only one
instance may be uysing config source at any moment. I simply don't know
how to do synchronization nor have time for this now
6. We also need a way to share address books, status/cache files, ...
I don't expect to be able to do this in these 2 weeks but I'll be
keeping it in mind and so my IMAP-based ConfigSource implementation
would use a general IMAPFile class which could be used to store any kind
of file on IMAP server.
I'd be grateful for any opinions about all this. Also, if anyone feels
like working on it, please let's share the work, otherwise I'll try to do
the minimum required to actually use all this during my holidays (I won't
have time to continue working on this in September I'm afraid). So I want
to start this a.s.a.p. and would appreciate any feedback.
Thanks,
VZ
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Mahogany-Developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mahogany-developers
