On Wed, 2009-12-16 at 08:13 +0000, Chen, Congwu wrote: > Patrick wrote: > >Nokia/default/ > > config.ini - main config template file > > internal.ini - matching criteria, only (?) used by code which > > searches for a template > > sources/ - sub-directory with source part of template > > > >How to define and the matching criteria is the key problem that we need > >to discuss - is that moved into the front-ends? > Do you mean each configuration template have a 'internal.ini' to identify it's > matching criteria?
Yes. > Maybe better to record them as a global index file? The templates is intended > to be read only, But this internal.ini is read-only - okay, except when creating that specific template, of course. Do you see a reason to write into this internal.ini file at runtime of SyncEvolution? > so a index file looks more reasonable. It may looks like this: > index.ini > server: templates/server/default > client: templates/client/default > SyncEvolution : templates/client/SyncEvolution/default > Phone: templates/client/phone/default > Nokia: templates/client/phone/nokia/default I see several drawbacks with that: - not a simple key/value format - adding new entries requires modifying one central file, which is what most programs move away from because keeping such a file consistent is difficult (/etc/apt/sources.list vs. /etc/apt/sources.list.d) and because it prevents system admins or individual users from simply dropping a new set of files into a directory which is searched by SyncEvolutution (we should find templates in /usr/share/syncevolution, /etc/defaults/syncevolution, $HOME/.config/syncevolution-templates) Not having a central index file comes with a slight performance cost, but because the whole list of templates is only needed infrequently (basically only when the user wants to configure a new device), this can be ignored. > The front end will let the user input as much as possible (phone? OS ? > Model?) and try > to return a most matched configuration template. We still need to decide how the front end accesses these templates and how they are combined with devices that are known to be available (MB #7089). > >> 2) Synchronization with another SyncML client over HTTP > >The question is how we integrate that into a SyncML server. Should we > >introduce a "default" peer config with username/password that is used to > >verify a peer and once it is authorized with that, create such a > >peer-specific config? > > > >As you said, such a config can be very simple. We don't even need to > >configure per-peer source properties. > I think that's what we have to do.. Added to MB #7838. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
