UAM
From Evolution
- Merge ESources in EAccount
- Deprecate ESources but still bridge them for external applications
- Rewrite ESourceSelector around EAccount for API/ABI compatibility
- Remove account setup from mailer and make it with shell/capplet (?)
- New addressbook/calendar/memo/tasks should be merged with EAccount
From evolution-hackers mailing list, I understand that UAM is done for split-ui. I am not sure if there is any real need for split-ui. A mail/calendar application without an address-book is of no use at all. When you are launching Evolution in a component (say Mail), the other components, (say calendar and task) are already not loaded anyway and hence I do not see any benefit of splitting up the components into separate applications. Instead of butchering evolution into various applications, only thing that we may need to add is "component-auto-unload-on-timeout" i.e., when a component is not looked for a prolonged period of time, we may unload the component, (Even in this case address-book should not be unloaded) silently. -- Sankar
Unified Account Management
What is UAM ? May be the following bullets might explain a bit:
- Mailer is using EAccount. No problem. But EAccount is not Calendar-capable. For instance, it will not know what is a free-busy url.
- Should all calendar and addressbooks be banned from using ESource and move completely to EAccount ?
- Why we need UAM ?
- Once we know what is UAM, probably the most pertinent question above will be answered.
- If it is for issues like: For GW, calendars and addressbooks are not created only, Mail getsan account ? If so, then the solution for this will be:
1) Currently when an account is created via the account-setup dialog, no matter whether the authentication is successful or not, EAccount is created.
2) Once EAccount is created, account-added event is emitted.
3) groupwise-account-setup plugin will listen to this event. Now, it tries to authenticate to the server and gets addresbook-names. If it does not contain "Frequent Contacts", the plugin recommends using some other client ;)
4) Now ESources are created for the default Calendar and the addresbook-names obtained above.
Problems in this approach are :
1) If the user was advised to "Use some other client", he has to re-enable the account. No way on earth, user will know of this work-around until told.
2) Any new addressbook created using some other client will not be listed anytime. Account needs to be disabled and re-enabled.
3) Evo should not recommend using another client but should rather create the personal and Frequent addressbooks by itself.
4) We either lack the API to get Calendar names or planned not to support any calendars except the default GroupWise system calendar.
If you are tempted to say, "Don't be a complaining #$@$@#$, what is the solution you propose ?" then it is:
1) When teh account is created, GAS plugin should create ESources for Address-book, Calendar and Task with just details like Username, Server address, SOAP Port etc.
2) Every time when a component is loaded, there is a open_calendar / open_addressbook call loaded. In this call, we should make a call for getAdddresbookNames and get teh response and update the ESources.
3) This way you dont miss addressbooks created using other clients and also you wont try to access obsolete adddressbooks causing user wonder "What is happening ?"
If there is a need for programmatically creating accounts without launching Evo,then also, we need to implement the above mentioned solution. After that, we need to make use of evolution-gconf-tools which will create accounts from a command-line. We need more fine details on how these accounts will be created ? (Zen/ Sabayon / ?) And what are their requirements ?
