Patrick wrote:
>> So how will we manage the configuration templates?
>
>Clearly our solution must scale much more than the current built-in
>templates and must be extensible at runtime. I suggest that we avoid
>adding such client templates to our source code and go entirely for
>template files (similar to what was started in MB #7808).
>
>> Per Manufacture+OS
>> version? i.e. Nokia_S40, Nokia_S60, ...
>
>I suggest we organize our templates around manufacturer, class of device
>(S40, S60, ...), and specific model:
>
>Nokia/
>   default/
>   S40/
>       default/
>       7120c/
>
>This is just for organizing the files in a more user-friendly way. The
>directory hierarchy itself has no meaning for our code. The matching
>criteria (vendor, class, model) should better be encoded in a more
>machine-readable format inside each directory.
>
>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?
Maybe better to record them as a global index file? The templates is intended
to be read only, 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

The front end will let the user input as much as possible (phone? OS ? Model?) 
and try
to return a most matched configuration template.
  
>> 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..

--
Best Regards,
Congwu

_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to