Re: [Evolution-hackers] New 'eclient' branch in eds

[Matthew Barnes <mbarnes redhat com>]

On Thu, 2011-04-28 at 14:49 +0200, Patrick Ohly wrote: 
> Please, let's avoid "E_CLIENT_TYPE_CALENDAR". For people less familiar
> with Evolution terminology it is not clear whether this includes tasks.
> In Evolution, it doesn't, but in other contexts it does. For example,
> Nokia phones store events and tasks in the same "Calendar". In
> SyncEvolution I followed the Evolution terminology and "calendar" has
> caused a lot of confusion.
> 
> It's not even obvious inside Evolution, because libe*cal*[endar] also
> does include tasks and memos.
> 
> What about E_CLIENT_TYPE_EVENTS instead?

It hadn't occurred to me the word "calendar" might be ambiguous.  I
blame the iCalendar spec for overloading it.  In the real world, one
does not make a "calendar of tasks", one makes a "list of tasks".

Maybe this is too Evolution-centric, but to me the container/item
relationship is clear:

   an ADDRESS_BOOK  contains  CONTACTS
    a CALENDAR      contains  EVENTS
    a TASK_LIST     contains  TASKS / TODOS
    a MEMO_LIST     contains  MEMOS / JOURNALS
    a MAIL_STORE    contains  MESSAGES

The enum values should be named consistently.  So if we change CALENDAR
to EVENTS, I think we should change the rest.

FWIW, the new ESource API is already using container names.  Key files
will have groups named [Address Book], [Calendar], [Task List], etc.
instead of [Contacts], [Events], [Tasks], etc.

To me it sounds more natural to refer to containers than items, but
maybe I'm too indoctrinated in Evolution-speak.