On Tue, 2005-01-04 at 13:41 +1100, Stewart Heitmann wrote:
> Thus I suggest it would ultimately be better if the sync engine only sent
> those
> particular vcard fields to a plugin that it knows the plugin can handle.
> However this requires each plugin to register the fields they handle with the
> sync
> engine on startup. Its a substantial design change so I dont imagine it would
> go into the 0.8x branch. Perhaps something to consider for 0.90 instead.
I second this; although the ultimate responsibility of data conversion
is of course on the individual plugin, the need to filter fields is very
common and should be provided by the framework. This should allow us to
map the Syncml device-info (capabilities) in a nice way and have a
chance of syncml actually working in the future.
Of course the choice of what functionality to include in the framework
is not always clear, and refactoring is the answer rather than huge
up-front desing. However, we've already seen the need for vcard 1/2/3
conversion and field/attribute filtering.
Mika Raento
--
Mika Raento mailto:[EMAIL PROTECTED] http://www.iki.fi/mikie/
"You can't *ADD* things and come out with *LESS* than you started with!"
"I can do that! It's a free country! I've got my rights!"
-from Calvin & Hobbes by Watterson
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Multisync-devel mailing list
Multisync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/multisync-devel
