Patrick wrote: 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. I think that's what we have to do.. -- Best Regards, Congwu

Patrick wrote: No, I mean the whole templates is intended to be read only, distributed during installation. This is why I prefer also distributing a central index file for searching. We have slightly different usage scenario with the below examples, it's the *template*, user will never need to modify the templates, he will/can edit his own configuration generated from the template. A central index file is indeed harder to maintain, but should be unlikely. And maybe a script can do that for help. Yes, the index file is more like a tree based structure, cannot reuse current code. Ok, agree so far. -- Best Regards, Congwu

Patrick Ohly wrote: True, I jumped the gun, suggesting a solution without explaining the problem... It could also be I'm trying to solve problems that we don't know exist yet. In any case here is my client side view on this. First, I was actually under the belief that SDP included vendor/device IDs but that doesn't seem to be the case. There are still some ways to do matching: 1) Syncml devices should responds to SDP service search for "SYNCML" 2) default device names are very commonly of type "Nokia N85" 3) Bluetooth addresses can be used to guess the vendor (IEEE OUI database) None of these is guaranteed to work so they should only be used as enhancements. Second, I was actually thinking we should provide the user an opportunity to input the device model name (I just forgot to mention this): I wasn't thinking about syncevolution config implementation at all at this point, so it might currently be impossible. I think this would theoretically be the best option UI wise: * show one item per paired device in the list (plus option to pair new devices, then come back to this list) * in the actual device configuration, let user choose from templates that syncevolution gives as matches for that device * let user change the name that is used in the matching, and update the list of available templates This sounds like something we just cannot do with current API. I think the only real alternative to this is to give the user the ability to select any device template. At this point I'm guessing the user input model would work better. The score sounds good but that drawback is a problem, and it was also why I originally asked about access to the full hierarchy. If my analysis on the bluetooth device identification in the beginning is correct then we can't expect to find a match for all devices. If it seems a good solution requires API changes, we can always implement the first version so it always returns N*M templates (where N is number of paired devices and M is number of device templates). It's clear that this will not work for a large number of templates but it would work for a few... I said earlier that it would also be nice to be able have templates for every phone we have tested (even if the phones work with a generic template) just so it's visible to user that it is tested. Maybe this wish could be solved otherwise: If the templates include a list of tested models (search strings), syncevolution could return e.g. template "S60 3rd gen" with perfect compatibility score for a phone with name "Nokia N85". - Jussi

Another possible solution: It is possible to trigger a dummy SyncML session and get the DevInfo from the phone. The 'Man' and 'Mod' fields provides precise for us to find the real template correctly (and abort the dummy session silently). We already need to work on this for HTTP based clients, I think it is possible to also make it work for Obex based phones. The only premise the phone responds with our SAN in the default dummy session. I think it is possible. See discussions in http://bugzilla.moblin.org/show_bug.cgi?id=7838#c8 Jussi Kukkonen wrote: Best Regards, Congwu

Chen, Congwu wrote: identify it's intended like this: Some UI comments: I assume it will be possible to query the template hierarchy and the selection/matching is done in client? The system should scale to fair number of templates: It should be possible to add "empty" templates, so we can show e.g. "Nokia N85" if it is a tested device even if it actually just uses "default Nokia S60". From a user POV the "device class" might or might not be useful: As an example, most Nokia users probably don't know the difference between S60 and S40 and it is not really advertized on the phone. This doesn't mean it's not useful in the implementation, just mentioning that it might not be shown on UI. - Jussi

On Tue, 2009-12-22 at 07:00 +0000, Chen, Congwu wrote: What is the format of these individual name components? Are they meant to be derived from "vendor" + "model" strings? Suppose we have a Nokia phone XYZ with no Nokia_XYZ template. Would we a) want and b) be able to give the "default" Nokia template a higher priority than the default templates of some other vendor? How would this get localized? For locally added entries the localization would have to be in the template itself, which is currently not supported. Currently we don't have such strings in GetConfigs(), do we? The SyncML server descriptions are treated as special cases in the sync-UI, which is localized. -- 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.