On Friday 01 February 2013 10:24:15 Patrick Ohly wrote: > On Thu, 2013-01-31 at 23:32 +0000, Graham Cobb wrote: > > The effect of this is that using just "syncevolution --print-databases" > > doesn't show anything, even if you do have an account configured. In > > fact, you have to name a "target-config" configuration, and exactly one > > source, to get the listing. You can't even set up any configuration of > > the default context which will allow "syncevolution --print-databases" > > to work. > > > > Is this expected and desired behaviour? > > No, desired is to list databases without any configuration if enough > information was provided.
I am still confused about configuration -- I still don't really have a good model in my head of the way configs work. But help me understand how this particular case should be working. Assume that activesyncd gconf is set up correctly (that is a different problem!). In that case, all the AcriveSync backend needs to be told is the account name. It expects to get it from the username parameter in the source config. For sync, it gets that from the target-config. And my getDatabases code works if I specify the target config in the --print-databases command, for example: syncevolution --print-databases target-config@Work calendar But it would be nice if "syncevolution --print-databases" would work. I tried to configure a username on the @default config: syncevolution --configure [email protected] @default But that isn't allowed: "per-peer (unshared) properties not allowed". Does CalDAV have the same problem or does it have a way to get the required information without explicitly specifying the configured target-config? > The reason why databases are listed by data category is that it allows > the D-Bus version of --print-databases (GetDatabases() = > http://api.syncevolution.org/#Server.GetDatabases) to return entries > which are suitable for the given backend. OK. Will do. I will work out a strategy for the caching (activesyncd keeps a cache -- the question is when to tell it to refresh that cache). > > eas_mail_handler_get_folder_list works (if I manually copy the parts of > > the header file that are needed). But I would prefer to use an API > > exported by libeassync as I don't see listing folders as mail-specific. > > That would mean adding a new function exported by libeassync and bumping > > the soname. Actually, I don't see that the library currently uses > > sonames -- is that right? It would mean, in any case, that the new > > syncevolution backend would require the new version of the libeasclient > > library to build. Any problem with that? > > No, fine with me. For the syncevolution.org binaries I am compiling and > bundling activesyncd. OK. That is what I will do. I will propose two patches, one to add a new function to libeassync and a separate one to use it in ActiveSync. Thanks for your help Patrick. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
