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. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
