Patrick Ohly wrote:
I assume it will be possible to query the template hierarchy and the
selection/matching is done in client?
I'm undecided about that. It moves logic away from the core server into
the UI, where it doesn't belong.
Before we can decide that, I think we should look at real-world use
cases for this, in other words, the integration into Bluetooth pairing.
What properties about the peer are known at that point? That is what we
can either present to the user or use for automatic matching against
suitable templates.
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.
We can do this without API changes:
* templates for the same peer will have the same syncURL
* a new property could give a score to describe how well the
underlying template in our database matches the device
Advantage of that approach: GUI doesn't need to know about device
attributes. Drawback: we don't present the full list of available
templates in our database.
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
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
