[Evolution-hackers] Mailer lockdown

[Not Zed <notzed ximian com>]

There's been mention in meetings, there's been blog entries, and maybe
even some code (?), but its time to kick off some discussion here, I
think.

The account settings is the hardest part, but we can also abstract them
mostly behind EAccount.

It seems at this point, the easiest solution isn't another xml config
library with more features (but hey, if we'd used my e-config design, it
could've been layered on top fairly easily ... :).

So we came up with something like:
 - some specific gconf keys, wherever they live, that define the
lockdown policies to apply.
 - logic inside EAccount to enforce the policies, on the specific fields
relevant to the lockdown policies requested
 - similar logic inside mail prefs and so on to enforce other policies

One of the problems is how to build the gui based on these policies.

For EAccount, probably the easiest is a method that can return read/
write status of each possible field in EAccount.

I would suggest a single method rather than a gaggle of methods for each
possible field.

e.g.

bool = e_account_is_writeable(EAccount *, e_account_field_t field)

We can then use this, on a per-field basis, to build the gui, together
with more broad policy stuff.  Of course it might be that we can just
use the broad policy stuff anyway, but then we need to duplicate some
logic between the two levels.

We probably also need accessor methods to set the fields, so the
settings can be enforced too.

I would also prefer a similar mechanism:

e_account_set(EAccount *, field, ...)

Rather than a bazillion set/get method pairs.  I thin kthe get method
should be optional, it wont add anything in non-threaded code like this.

Live updating of the lockdown state shouldn't be too much of an issue.


This doesn't cover being able to set specific values for settings 'on
the fly', it assumes it comes preconfigured in the right state, which we
dont want to allow you to change.


What do we need to work out at least:
 - what policies we want
 - how to break up these policies into a set of gconf keys
 - how to map these gconf key policies to the ui and backend parts, i.e.
specific ui elements and specific account fields.