On Wed, 2009-12-16 at 10:07 +0000, Chen, Congwu wrote:
> Patrick wrote:
> >On Wed, 2009-12-16 at 08:13 +0000, Chen, Congwu wrote:
> >> 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?
>
> No, I mean the whole templates is intended to be read only, distributed
> during installation.
Some parts of it are, the ones provided by us. The parts provided by a
system admin (/etc) or the user ($HOME) are writable.
> This is why I prefer also distributing a central index file for searching.
What is the benefit that you see in that?
Setting up such an index file would work if the index file could be
created once when we build our distribution package. It becomes very
awkward as soon as we allow adding to that database after installation.
On Wed, 2009-12-16 at 09:28 +0000, Jussi Kukkonen wrote:
> Some UI comments:
>
> 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.
> 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".
What I could imagine is that D-Bus server does the matching and then
presents a set of templates via GetConfigs(templates=true) that could be
used to set up the paired device:
* Nokia N85, using Nokia N80 template
* Nokia N85, using generic Nokia template
* Nokia N85, using default template
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.
> 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.
You are probably right. I also suspect that we won't be able to
determine that device class anyway.
--
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
