opensync-devel — The place to coordinate the development of OpenSync

[Opensync-devel] Question about new field (FN) after sync.

[Douglas L. P. <dou...@gm...>]

Hi everyone,

I've successfully installed opensync0.22 on my Debian box (running
2.6.30 kernel) and also msynctool. I've also configured it to sync my
Nokia 5310 (using syncml and file plug-ins).

When the sync finished, I noticed that some information was sent to my
phone (I saw it in the logs shown in the terminal).

Browsing my contacts in the phone I saw that the name of the contacts
were duplicated. The field added has as identification the letters FN
(formal name?).

Does anyone knows why were those fields added?

Thank you for your attention.

Regards,
Douglas

Re: [Opensync-devel] [Req. for Michael] Need help getting File<=>SyncML (Google) to work

[Michael B. <mic...@cm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Joël,

Joël Bourquard wrote:
>
> Then, to avoid attacking evolution directly, I decided to try syncing
> between files (on my filesystem) <=> SyncML (on gmail). With the kind
> help from Daniel, we configured everything and built latest SVN, but it
> seems the synchronization takes forever, and does no network activity at
> all.
> 
> Daniel has a look at the traces but we didn't reach any conclusion yet.
> He advised that I asked for your insight.
> 
> What would you recommend to try next ?

Can I get the traces from you? You can open a ticket for this issue but
please check your traces twice to avoid publishing your passwords or
accounts.

Actually I'm really busy because I have some kind of a new job and I
discovered that libsyncml does not support huge maps.

Best regards

Michael
- --
___________________________________________________________________

Michael Bell                        Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482           ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704           Unter den Linden 6
mic...@cm...       D-10099 Berlin
___________________________________________________________________

PGP Fingerprint: 09E4 3D29 4156 2774 0F2C  C643 D8BD 1918 2030 5AAB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq7VkMACgkQ2L0ZGCAwWqvj1gCgvdFCPBuDtJ7Zoc66rKNuQsLM
aukAoMqTijjIh9rJessfuV8ObwrJNVVb
=KVch
-----END PGP SIGNATURE-----

[Opensync-devel] [Req. for Michael] Need help getting File<=>SyncML (Google) to work

[Joël B. <wor...@gm...>]

Hi Michael,

I've been trying to synchronize an evolution contact list with my
Android device (an HTC Hero) which doesn't support SyncML.

Therefore I thought the best way was to sync with my gmail account,
which the device already syncs with.

The following command works already, and displays all contacts from my
account:

syncml-ds-tool --http-client https://m.google.com/syncml --slow-sync
text/x-vcard contacts --username joel.bourquard --password MY_PASSWORD
--wbxml

Then, to avoid attacking evolution directly, I decided to try syncing
between files (on my filesystem) <=> SyncML (on gmail). With the kind
help from Daniel, we configured everything and built latest SVN, but it
seems the synchronization takes forever, and does no network activity at
all.

Daniel has a look at the traces but we didn't reach any conclusion yet.
He advised that I asked for your insight.

What would you recommend to try next ?

Many thanks in advance,

Joël


On Mon, 2009-09-14 at 14:22 +0200, Daniel Gollub wrote:
> On Friday 11 September 2009 09:20:20 pm Joël Bourquard wrote:
> > I have looked with wireshark but can't find any traffic from/to the
> > SyncML plugin. Did you find something on this ?
> > 
> 
> Nope - sorry. Was on vacation last weekend - i'll be quite busy this week. 
> Could you ping me about this issue next Weekend - or ask on the Mailinglist? 
> Maybe Michael (libsyncml Maintainer) can help ...
> 
> Best Regards,
> Daniel
> 

Re: [Opensync-devel] Porting instructions for new Capabilities ??

[Henrik /K. <kaa...@us...>]

Dear all,

I am trying to port mozilla-sync to the new OpenSync API.
The version checked-in as revision 5823 compiles.

mozilla-sync can sync two things:
- contacts in xmlformat
- events in vevent format

The current revision works for contacts/xmlformat.
However, it fails for events/vevent.

I am doing the following:
pCapabilities=osync_capabilities_new("vformat", ppOSyncError);
pCapabilitiesObjType=osync_capabilities_objtype_new(pCapabilities, 
"event", ppOSyncError);
Loop over
pCapability = osync_capability_new(pCapabilitiesObjType, ppOSyncError);
osync_capability_set_name(pCapability, sz);
for sz = Alarm, AlarmRelatedEnd, Attach, Attendee, CalendarScale, ...

When trying to sync this to file-sync I get:
ERROR: Couldn't handle the capabilities in format "vevent" to process a 
reported change in format "xmlformat-event"
EXIT_ERROR: _osync_obj_engine_clone_and_demerge_change: Couldn't handle 
the capabilities in format "vevent" to process a reported change in 
format "xmlformat-event"
EXIT_ERROR: _osync_obj_engine_mapping_find: Couldn't handle the 
capabilities in format "vevent" to process a reported change in format 
"xmlformat-event"
EXIT_ERROR: osync_obj_engine_map_changes: Couldn't handle the 
capabilities in format "vevent" to process a reported change in format 
"xmlformat-event"

Can anybody spot some obvious coding error on my part here?

Thanks in advance

/Henrik


Henrik /KaarPoSoft wrote:
> Dear OpenSync developers,
>
> It is GREAT to see progress towards 0.40. Thanks a lot!
>
> I was wondering if there are any porting instructions for the new way of 
> handling capabilities...
>
> In mozilla-sync
> http://opensync.org/browser/plugins/mozilla-sync/trunk/src/mozilla-sync.cpp
> I have calls to osync_capability_new (line 911), but the API seems to 
> have changed...
>
> Any hints on how to fix this?
>
> /Henrik
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
>   

Re: [Opensync-devel] Ticket 1078 - Remove pendingLimit from OSyncQueue

[Henrik /K. <kaa...@us...>]

Dear all,

I am not familiar enough with the inner workings of OpenSync to comment 
on the details ))-:

However, I do think a fix is necessary.
It is great to freeze the API for 0.39/0.40, but it would be great if it 
would actually work too!

/Henrik



Christian Hilgers wrote:
> Graham Cobb schrieb:
>
>   
>> The risk is that the real fix may involve an API change.  However, I think 
>> that can be done with (i) no changes needed in plugins which do not do the 
>> SyncML-style batching, and (ii) the API changes would be limited to some 
>> additonal functions, not changes to the existing API.
>>     
>
> This should be possible without an API break, so no stopper for releasing 0.39
>
> Christian
> --


Graham Cobb wrote:
> On Friday 18 September 2009 01:22:25 Henrik /KaarPoSoft wrote:
>   
>> Are there any progress / comments / plans on ticket 1078?
>> See also comments on the mailinglist regarding
>> "Remove pendingLimit from OSyncQueue".
>>     
>
> I was hoping someone might comment on my suggestion back in April (attached).  
> On the other hand, I have not done anything about it since that message -- 
> not even drafted the API necessary to implement my suggestion.  My fault, 
> sorry.
>
>   
>> As far as I can see, this problem prevents any sync with SyncML devices,
>> as the SyncML protocol may have several changes in one message,
>> which I believe OpenSync cannot handle now...
>>     
>
> My proposal is to disable the timeout handling completely for now and for me 
> (or someone else if they wish) to implement a real fix over the next few 
> months.  I am not going to get a chance to work on this for the next several 
> weeks, unfortunately (although I can check in a change to just disable 
> timeout handling straight away if that is what people want).
>
> The risk is that the real fix may involve an API change.  However, I think 
> that can be done with (i) no changes needed in plugins which do not do the 
> SyncML-style batching, and (ii) the API changes would be limited to some 
> additonal functions, not changes to the existing API.
>
> Graham
>   
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Opensync-devel] [RFC] Remove pendingLimit from OSyncQueue
> From:
> Graham Cobb <g+o...@co...>
> Date:
> Sat, 25 Apr 2009 17:22:00 +0100
> To:
> Daniel Gollub <go...@b1...>
>
> To:
> Daniel Gollub <go...@b1...>
> CC:
> Michael Bell <mic...@cm...>, Opensync Devel 
> <ope...@li...>
>
>
> On Tuesday 14 April 2009 13:39:43 Daniel Gollub wrote:
>   
>> On Tuesday 14 April 2009 02:25:29 pm Michael Bell wrote:
>>     
>>> I don't think that a dependency between two pipes is a good idea but I
>>> understand that IPC has limits. I also used IBM MQ series in the past
>>> which has nothing to do with IPC. So is our message queue implementation
>>> a real IPC implementation which requires limits?
>>>       
>> No Idea - maybe Graham kann answer this.
>>     
>
> Sorry about the delay -- I have been away and have not had a chance to spend 
> any time on this until today.
>
> I understand the problem, and the current timeout/limit mechanism definitely 
> deadlocks with the way the async plugins work today (I am ignoring any 
> changes suggested in this thread as I am not sure I understand exactly what 
> has been proposed).
>
> The pendingLimit is there to allow timeouts to work properly.  If the 
> pendingLimit is just removed, the timeouts will break as they did before (the 
> timeout starts counting at the wrong time and so if there are a large number 
> of transactions queued up the timeout fires too early).  But let's review 
> what timeouts are for and how we would **like** them to behave.
>
> As I understand it, the main purpose of the timeouts is to deal with cases 
> where the remote device (or some intermediary) has got stuck and is no longer 
> proceeding with transactions (but not returning errors).  It also helps with 
> cases where the plugin tries to send a message but does not notice that there 
> is an error (e.g. a socket has been disconnected) and it will never get a 
> reply.  This is, of course, a plugin bug but it is useful that the timeout 
> mechanism also protects against that problem.
>
> There is a secondary use for timeouts and that is to protect against problems 
> in the IPC mechanism itself -- e.g. a process has stopped and is no longer 
> reading the pipe.  This is a smaller consideration and can be handled by 
> mechanisms within the IPC itself if necessary, so let's ignore it for now.
>
> There seem to be three plugin architectures which are relevant (I thought, 
> when I was rewriting the timeout code, that there were only the first two but 
> I now realise there is a third):
>
> 1) Synchronous plugin (most plugins are like this, I believe): when a 
> transaction is received by the plugin (e.g. Connect or Get Changes or Commit) 
> it does synchronous writes to send messages to the device and synchronous 
> reads to get messages from the device.  If the device stops responding, the 
> thread executing the plugin will just wait.  No other plugin messages will be 
> handled while it is waiting.
>
> 2) Asynchronous but transaction-at-a-time plugin (maybe there are none like 
> this): when the transaction is received, the plugin sends the message to the 
> device and then returns.  The thread polls the socket and resumes when the 
> response is received. However, other plugin messages can be handled while it 
> is waiting -- so further updates will cause further messages to be sent to 
> the device.  If the device stops responding, the engine will keep sending 
> updates which the plugin will send. although it is not seeing any responses.
>
> 3) Aysnchronous, multiple transaction plugin (like SyncML): when the 
> transaction is received, it is stored internally to the plugin.  Nothing is 
> sent until a message fills up or the last transaction is received. Then all 
> updates are sent and, when responses are received, the updates are completed.  
> If the device stops responding then all or some updates will not receive a 
> response.
>
> For 1 and 2, the timeout is protecting each single commit and the value should 
> be set based on the time needed for that transaction.  In the case of 2, this 
> means the pendingLimit is needed -- it limits the number of updates that 
> might already be queued ahead of this one and so allows the timeout value to 
> be calculated (i.e. pendingLimit * maximum time for one update).
>
> For 3, however, it is much harder.  One option would be to set the timeouts 
> for each commit (and the commit_all) based on the time the device needs to 
> complete a maximum sized message of updates.  On the other hand, that doesn't 
> allow for the fact that the OpenSync engine itself might take some time (in 
> complex cases) to even provide enough updates to fill a message: timeouts 
> were not intended to have to take into account OpenSync engine processing.
>
> Another option for 3 is to set no timeouts at all on the individual commits, 
> but set a timeout on the commit_all.  The problem with that is that the 
> timeout value for the commit_all is potentially unlimited (it is not limited 
> to a single message of commits as the commit_all will start as soon as the 
> commits have all been queued and hundreds of messages may have been sent to 
> the device).
>
> On the other hand, the plugin itself knows what is going on.  So, I think the 
> best option for case 3 is for the plugin itself to control the timeouts.  I 
> suggest that in this case, there are no timeouts on the commit or commit_all, 
> but that the plugin itself sets a timeout when it has assembled a message and 
> sent it to the device.  I.e. add some sort of OsyncStartTimeout(int timeout) 
> and OSyncStopTimeout() calls.  The plugin would start the timeout when the 
> first message was sent to the device.  Whenever a response is received, the 
> timeout would be stopped and, if there were one or more messages still 
> waiting for responses, it would be started again.  If the timeout actually 
> fires, then the OSyncQueue code completes all pending operations with a 
> timeout error (just as in the existing timeout processing).
>
> This does mean that for plugins using this third architecture, they have to 
> have some extra complexity.  But I can't see an alternative, if we want to 
> keep the timeout protection.  Of course, we could decide that for this 
> release of OpenSync that we disable timeout processing altogether -- and add 
> it back in later (with additions to the API at that time).
>
> Does anyone have an alternative suggestion?  If not, I will spec up a 
> suggested API for the timeout operations.
>
> Graham
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>   

[Opensync-devel] OpenSync release 0.39

[Bjšo. R. <bjo...@go...>]

Hi everyone,

after a long time we finally released OpenSync 0.39. This will be the
last experimental release before 0.40. You can find the details in the
release notes.

Release Notes:


Yet another E.X.P.E.R.I.M.E.N.T.A.L. release of OpenSync. This release
is intended for developers, testers and for packages. OpenSync 0.3x
releases aren't intended to be stable. We don't recommend this release
for productive use. We don't recommend this release to be packaged as
part of a distribution.

--- end of sad/scary disclamer ---

This is our last release until the next stable release. The complete API
was examined and should be stable.
Changes since last release:

    * Updates and improvements in the API documentation based on doxygen
(ticket #755). Moved doxygen annotations from the source files to the
headers (ticket #898)
    * Shrinked the public API. Less public interfaces for plugins and
applications.
    * Removed XML format from OpenSync core. Now XML format is
maintained separately
    * Reference counting for all OpenSync modules (#978)
    * Sync plugin API changes
          o Introduce optional plugin sink function "connect_done". This
plugin function gets called after connect() and before get_changes().
          o Removed "write" function. This plugin function was never
used inside the engine and just causes confusion. Currently there is
also no need for a "sync framework" to do "single writes" out of sync order
    * Format plugin API changes
          o Implemented optional "validation" format plugin function.
This function is intended to get called after each format conversion
which end in the format plugin specific format, which provide such
validation function (#910)
          o Introduced osync_objformat_set_finalize_func and
osync_objformat_set_initialize_func for the public API. Those function
allow to register format-plugin specific initalize/finalize functions.
Which get called when the format-plugin get loaded by the
format-environment. This function allow to allocated user-data which
will be passed with all format-plugin calls. And must get released
within the finalize call.
          o Changed all format specific function signatures to pass a
void *user_data pointer. Now it is possible to create format specific
data in initialize which gets passed to all other format functions (#1019)
          o Introduced caps_converter function osync_bool (*
OSyncFormatCapsConverterFunc) (OSyncCapabilities *oldcaps,
OSyncCapabilities **newcaps, OSyncError **error); (#1146)
          o Dropped merge/demerge function. Now merge/demere is
independent of formats (#1084)
    * New IPC implementation by Graham Cobb
    * Support for ObjType mixing in OSyncEngine (#992)
    * Multiply callback for synchronization forecast (#850)
    * Format independent use of merge/demerge via new OSyncCapabilities
and OSyncMerger (#1084)
    * Common list pattern for all OpenSync modules (#975)
    * Dropped file location from OSyncHashtable interface (#1082 and #1083)
    * Dropped file location from OSyncAnchor interface
    * Key=value pattern for OSyncAnchor (#1090)
    * Replace OSyncAnchor with OSyncStateDB (#1091)
    * Improved exception handling in all OpenSync modules (#1087)
    * Started to write new OpenSync API usage examples for 0.40 API (#972)

Next steps:

    * Bugfixing: Open Tickets for 0.40
    * Testing
    * Review the internal API
    * Complete the API documentation
    * Finishing OpenSync Whitepaper
    * Porting other plugins to latest changes for 0.3X

Release tarballs:

 http://opensync.org/download/releases/0.39/

Thanks to everyone for actively contributing to the OpenSync project by
testing, writing code, updating tickets and keeping the project alive!

Re: [Opensync-devel] Preparing for OpenSync API 0.40 soft-freeze

[Rainer D. <rd...@we...>]

Hi Daniel,

Am Donnerstag, 17. September 2009 schrieb Daniel Gollub:
> Hi,
>
> could you all double-check the public interfaces of the OpenSync trunk API,
> if they fit your needs for you application/plugin ... (those which got
> exported by the OSYNC_EXPORT macro)
>
> I plan to _soft_ freeze thursday evening/night (CEST) the OpenSync API and
> do a quick accepteance test with various "hot-requested" plugins ... and
> port those which aren't yet ported. If you need assistance porting - please
> drop a mail on opensync-devel mailing list.
>
> By "soft freeze" i plan to accept API-breaking changes after 0.39 which
> meets following criteria:
>
>  - (only) critical bugfix
>
>
>  - not for additional feature or enhancemnet
>  - not cosmetic API cleanup
>
>
> JFYI, there is only one ticket left for the 0.39 milestone which is waiting
> for validation if we have proper error-handling for all public Interfaces.

I have devices which use irmc-sync and syncml-obex-client. Do you think it is 
already worth to do testing with these plugins?

Thanks,
Rainer


-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rd...@we...
jabber: rd...@ja...
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/

Re: [Opensync-devel] [PATCH] API change to osync_time_utcoffset2sec()

[Chris F. <cd...@fo...>]

On Sat, Sep 19, 2009 at 01:58:00PM +0200, Daniel Gollub wrote:
> On Saturday 19 September 2009 12:27:42 am Chris Frey wrote:
> > The following patch changes the API, so I post it here for review.
> 
> Looks O.K. to me. Plesae commit ASAP. I'll tag 0.39 after that.

Committed.  Thanks.

- Chris

Re: [Opensync-devel] [PATCH] API change to osync_time_utcoffset2sec()

[Daniel G. <go...@b1...>]

On Saturday 19 September 2009 12:27:42 am Chris Frey wrote:
> Hi,
> 
> I noticed there was some error handling cleanup done in opensync_time.c
> so I took the time to clarify the documentation on the return codes.
> I commited one patch already which was fairly innocuous.
> 
> The following patch changes the API, so I post it here for review.

Looks O.K. to me. Plesae commit ASAP. I'll tag 0.39 after that.

Best Regards,
Daniel


-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] Preparing for OpenSync API 0.40 soft-freeze

[Chris F. <cd...@fo...>]

On Fri, Sep 18, 2009 at 09:42:18AM +0200, Daniel Gollub wrote:
> If the plugin function only pass OSyncContext* you need to repot the error 
> with osync_context_report_error() and then unref it again ;/
> 
> If the function get called with OSyncError** you don't unref it.
> 
> Does this make sense? Looks pretty confusing ... but i hesistate to touch this 
> interfaces again ....

That clears things up for me, thanks!

- Chris

[Opensync-devel] [PATCH] API change to osync_time_utcoffset2sec()

[Chris F. <cd...@fo...>]

Hi,

I noticed there was some error handling cleanup done in opensync_time.c
so I took the time to clarify the documentation on the return codes.
I commited one patch already which was fairly innocuous.

The following patch changes the API, so I post it here for review.

- Chris



Fixed osync_time_utcoffset2sec()'s mistaken reliance on sscanf()

Tightened up checking for input format validation, according to
the documented comments.

Added an OSyncError parameter, for the error case.

Added a test for osync_time_utcoffset2sec()
---
 opensync/format/opensync_time.c |   23 ++++++++++++++++++-----
 opensync/format/opensync_time.h |    6 ++++--
 tests/format-tests/check_time.c |   36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/opensync/format/opensync_time.c b/opensync/format/opensync_time.c
index 5f1ac9e..8a5939a 100644
--- a/opensync/format/opensync_time.c
+++ b/opensync/format/opensync_time.c
@@ -21,6 +21,7 @@
  */
 
 #include <time.h>
+#include <ctype.h>
 
 #include "opensync.h"
 #include "opensync_time.h"
@@ -627,19 +628,31 @@ error:
 	return NULL;
 }
 
-int osync_time_utcoffset2sec(const char *offset)
+int osync_time_utcoffset2sec(const char *offset, OSyncError **error)
 {
 	char csign = 0;
 	int seconds = 0, sign = 1;
 	int hours = 0, minutes = 0;
 	osync_trace(TRACE_ENTRY, "%s(%s)", __func__, offset);
 
-	sscanf(offset, "%c%2d%2d", &csign, &hours, &minutes);
+	// make sure the format of offset is what we expect: [-+][0-9]{4}
+	if( strlen(offset) >= 5 &&
+	    (offset[0] == '-' || offset[0] == '+') &&
+	    isdigit(offset[1]) && isdigit(offset[2]) &&
+	    isdigit(offset[3]) && isdigit(offset[4]) &&
+	    sscanf(offset, "%c%2d%2d", &csign, &hours, &minutes) == 3 )
+	{
 
-	if (csign == '-')
-		sign = -1;
+		if (csign == '-')
+			sign = -1;
 
-	seconds = (hours * 3600 + minutes * 60) * sign; 
+		seconds = (hours * 3600 + minutes * 60) * sign; 
+
+	}
+	else {
+		osync_error_set(error, OSYNC_ERROR_GENERIC, "%s: unable to parse utc offset into seconds: %s", __func__, offset);
+		osync_trace(TRACE_INTERNAL, "%s: unable to parse utc offset into seconds: %s", __func__, offset);
+	}
 
 	osync_trace(TRACE_EXIT, "%s: %i", __func__, seconds);
 	return seconds;
diff --git a/opensync/format/opensync_time.h b/opensync/format/opensync_time.h
index a7cebbb..cc237f8 100644
--- a/opensync/format/opensync_time.h
+++ b/opensync/format/opensync_time.h
@@ -263,9 +263,11 @@ OSYNC_EXPORT char *osync_time_vtime2localtime(const char* utc, int offset, OSync
 /** @brief Function converts UTC offset string in offset in seconds
  *
  * @param offset The offset string of the form a timezone field (Example +0200) 
- * @returns seconds of UTC offset 
+ * @error An OSyncError struct
+ * @returns seconds of UTC offset. On error, osync_error_is_set(error) is
+ *	true, and the return value is 0.
  */ 
-OSYNC_EXPORT int osync_time_utcoffset2sec(const char *offset);
+OSYNC_EXPORT int osync_time_utcoffset2sec(const char *offset, OSyncError **error);
 
 /*@}*/
 
diff --git a/tests/format-tests/check_time.c b/tests/format-tests/check_time.c
index 1cccf82..bc30cc3 100644
--- a/tests/format-tests/check_time.c
+++ b/tests/format-tests/check_time.c
@@ -211,9 +211,45 @@ START_TEST (time_unix_converters)
 }
 END_TEST
 
+START_TEST (time_utc_offset)
+{
+	OSyncError *error = NULL;
+	int seconds;
+
+	// UTC offset format is %c%2d%2d, i.e. +0200
+
+	// test missing lead char
+	osync_time_utcoffset2sec("0400", &error);
+	fail_unless(osync_error_is_set(&error), NULL);
+	osync_error_unref(&error);
+	error = NULL;
+
+	// test missing numbers
+	osync_time_utcoffset2sec("-040", &error);
+	fail_unless(osync_error_is_set(&error), NULL);
+	osync_error_unref(&error);
+	error = NULL;
+
+	// test correct operation [1]
+	seconds = osync_time_utcoffset2sec("-0400", &error);
+	fail_unless(!osync_error_is_set(&error), NULL);
+	fail_unless(seconds == -(4 * 60 * 60), NULL);
+	osync_error_unref(&error);
+	error = NULL;
+
+	// test correct operation, with trailing chars [2]
+	seconds = osync_time_utcoffset2sec("-0400555", &error);
+	fail_unless(!osync_error_is_set(&error), NULL);
+	fail_unless(seconds == -(4 * 60 * 60), NULL);
+	osync_error_unref(&error);
+	error = NULL;
+}
+END_TEST
+
 OSYNC_TESTCASE_START("time")
 OSYNC_TESTCASE_ADD(time_timezone_diff)
 OSYNC_TESTCASE_ADD(time_relative2tm)
 OSYNC_TESTCASE_ADD(time_unix_converters)
+OSYNC_TESTCASE_ADD(time_utc_offset)
 OSYNC_TESTCASE_END
 
-- 
1.6.2.5

Re: [Opensync-devel] Ticket 1078 - Remove pendingLimit from OSyncQueue

[Christian H. <Chr...@co...>]

Graham Cobb schrieb:

> The risk is that the real fix may involve an API change.  However, I think 
> that can be done with (i) no changes needed in plugins which do not do the 
> SyncML-style batching, and (ii) the API changes would be limited to some 
> additonal functions, not changes to the existing API.

This should be possible without an API break, so no stopper for releasing 0.39

Christian
--
Christian Hilgers                  |ConSol*
Tel.   +49.2102.994-423            |Consulting&Solutions Software GmbH
Fax    +49.2102.994-411            |Berliner Str. 101, 40880 Ratingen
email: Chr...@co... |WWW: http://www.consol.de

Re: [Opensync-devel] Ticket 1078 - Remove pendingLimit from OSyncQueue

[Graham C. <g+o...@co...>]

On Friday 18 September 2009 01:22:25 Henrik /KaarPoSoft wrote:
> Are there any progress / comments / plans on ticket 1078?
> See also comments on the mailinglist regarding
> "Remove pendingLimit from OSyncQueue".

I was hoping someone might comment on my suggestion back in April (attached).  
On the other hand, I have not done anything about it since that message -- 
not even drafted the API necessary to implement my suggestion.  My fault, 
sorry.

> As far as I can see, this problem prevents any sync with SyncML devices,
> as the SyncML protocol may have several changes in one message,
> which I believe OpenSync cannot handle now...

My proposal is to disable the timeout handling completely for now and for me 
(or someone else if they wish) to implement a real fix over the next few 
months.  I am not going to get a chance to work on this for the next several 
weeks, unfortunately (although I can check in a change to just disable 
timeout handling straight away if that is what people want).

The risk is that the real fix may involve an API change.  However, I think 
that can be done with (i) no changes needed in plugins which do not do the 
SyncML-style batching, and (ii) the API changes would be limited to some 
additonal functions, not changes to the existing API.

Graham

Re: [Opensync-devel] Preparing for OpenSync API 0.40 soft-freeze

[Daniel G. <go...@b1...>]

On Friday 18 September 2009 05:15:37 am Chris Frey wrote:
> Just to refresh my memory, I know that in the usage above, I'm responsible
> for unref'ing the error, since I'm the only one that sees it.

Right. But acutally we should avoid that any error gets lost inside a plugin. 
So the idea is to pass all error via the OSyncError** parameter to the 
OpenSync Framework or via osync_context_report_error() if there is a context 
pointer.


> 
> But if an OSyncError **error is passed in to my function, am I still
> responsible for unref'ing it?

Thats indeed confusing.

If the plugin function only pass OSyncContext* you need to repot the error 
with osync_context_report_error() and then unref it again ;/

If the function get called with OSyncError** you don't unref it.


Does this make sense? Looks pretty confusing ... but i hesistate to touch this 
interfaces again ....

> This almost seems like the responsibility
> of the calling code, but in the sample plugin, the error is unref'd

The example plugin might be outdated - so if there is anything fishy in it - 
then it's very likely wrong.

> even inside get_sync_info().  I don't know why the pointer is being passed
> in if I'm responsible for unref'ing it.
>

Arrgg indeed. Thats wrong ... thanks for the hint.

Best Regards,
Daniel


-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] Preparing for OpenSync API 0.40 soft-freeze

[Chris F. <cd...@fo...>]

On Thu, Sep 17, 2009 at 09:17:03PM -0400, Chris Frey wrote:
>  OSyncXMLField *convert_vcal_rrule_to_xml(OSyncXMLFormat *xmlformat, VFormatAttribute *attr, const char *rulename, OSyncError **error)
> @@ -305,6 +312,7 @@ static char *convert_rrule_vcal_until(const char *until_utc)
>  {
>  	int offset = 0; 
>  	char *until = NULL;
> +	OSyncError *error = NULL;
>  
>  

[...]

> +	until = osync_time_vtime2localtime(until_utc, offset, &error);
> +
> +	if( error != NULL ) {
> +		osync_trace(TRACE_ERROR, "%s: %s" , __func__, osync_error_print(&error));
> +		osync_error_unref(&error);
> +	}


Just to refresh my memory, I know that in the usage above, I'm responsible
for unref'ing the error, since I'm the only one that sees it.

But if an OSyncError **error is passed in to my function, am I still
responsible for unref'ing it?  This almost seems like the responsibility
of the calling code, but in the sample plugin, the error is unref'd
even inside get_sync_info().  I don't know why the pointer is being passed
in if I'm responsible for unref'ing it.

Thanks,
- Chris

Re: [Opensync-devel] Preparing for OpenSync API 0.40 soft-freeze

[Chris F. <cd...@fo...>]

On Thu, Sep 17, 2009 at 02:57:11AM +0200, Daniel Gollub wrote:
> Hi,
> 
> could you all double-check the public interfaces of the OpenSync trunk API, if 
> they fit your needs for you application/plugin ... (those which got exported 
> by the OSYNC_EXPORT macro)

Hi Daniel,

I figured I'd give the Barry 0.3x/0.4x plugin a test compile, but I got
stuck before I got there trying to compile the vformat plugin.

The OSyncError** changes to the time API don't seem to have trickled through,
and now, if I understand correctly, there's a lot of opportunity for leaks.

For example, this partial patch shows that there is **error cleanup needed
even inside error handling if() blocks...

Is this the planned way to fix this, or am I missing something?

Thanks,
- Chris



diff --git a/src/xmlformat-recurrence.c b/src/xmlformat-recurrence.c
index f8fffd5..87edf3b 100644
--- a/src/xmlformat-recurrence.c
+++ b/src/xmlformat-recurrence.c
@@ -115,6 +115,7 @@ static void convert_vcal_rrule_countuntil(OSyncXMLField *xmlfield, const char *d
 	int count;
 	int offset = 0; 
 	char *until = NULL;
+	OSyncError *error = NULL;
 
 	/* COUNT: #20 */
 	if (sscanf(duration_block, "#%d", &count) == 1) {
@@ -132,12 +133,13 @@ static void convert_vcal_rrule_countuntil(OSyncXMLField *xmlfield, const char *d
 		 */
 
 		if (!osync_time_isutc(duration_block)) {
-			struct tm *ttm = osync_time_vtime2tm(duration_block);
-			offset = osync_time_timezone_diff(ttm);
+			struct tm *ttm = osync_time_vtime2tm(duration_block, &error);
+			offset = osync_time_timezone_diff(ttm, &error);
+
 			g_free(ttm);
 		}
 
-		until = osync_time_vtime2utc(duration_block, offset);
+		until = osync_time_vtime2utc(duration_block, offset, &error);
 	} else {
 		until = g_strdup(duration_block);
 	}
@@ -145,6 +147,11 @@ static void convert_vcal_rrule_countuntil(OSyncXMLField *xmlfield, const char *d
 	FIXME_xmlfield_set_key_value(xmlfield, "Until", until);
 
 	g_free(until);
+
+	if( error != NULL ) {
+		osync_trace(TRACE_ERROR, "%s: %s" , __func__, osync_error_print(&error));
+		osync_error_unref(&error);
+	}
 }
 
 OSyncXMLField *convert_vcal_rrule_to_xml(OSyncXMLFormat *xmlformat, VFormatAttribute *attr, const char *rulename, OSyncError **error)
@@ -305,6 +312,7 @@ static char *convert_rrule_vcal_until(const char *until_utc)
 {
 	int offset = 0; 
 	char *until = NULL;
+	OSyncError *error = NULL;
 
 
 	/* UNTIL: 20070515T120000 */
@@ -313,10 +321,15 @@ static char *convert_rrule_vcal_until(const char *until_utc)
 	 * in the same Timezone as the host.
 	 */
 
-	struct tm *ttm = osync_time_vtime2tm(until_utc);
-	offset = osync_time_timezone_diff(ttm);
+	struct tm *ttm = osync_time_vtime2tm(until_utc, &error);
+	offset = osync_time_timezone_diff(ttm, &error);
 	g_free(ttm);
-	until = osync_time_vtime2localtime(until_utc, offset);
+	until = osync_time_vtime2localtime(until_utc, offset, &error);
+
+	if( error != NULL ) {
+		osync_trace(TRACE_ERROR, "%s: %s" , __func__, osync_error_print(&error));
+		osync_error_unref(&error);
+	}
 
 	return until;
 
diff --git a/src/xmlformat-vcalendar.c b/src/xmlformat-vcalendar.c
index 46320b7..76ab132 100644
--- a/src/xmlformat-vcalendar.c
+++ b/src/xmlformat-vcalendar.c
@@ -268,6 +268,7 @@ VFormatAttribute *handle_xml_vcal_alarm_attribute(VFormat *vevent, OSyncXMLField
 
 	const char *action = osync_xmlfield_get_key_value(xmlfield, "AlarmAction");
 	const char *trigger = osync_xmlfield_get_key_value(xmlfield, "AlarmTrigger");
+	OSyncError *error = NULL;
 
 	// trigger and action are required
 	if (trigger && action) {
@@ -318,15 +319,15 @@ VFormatAttribute *handle_xml_vcal_alarm_attribute(VFormat *vevent, OSyncXMLField
 		}
 		
 		duration = osync_time_alarmdu2sec(trigger);	
-		dtstarted = osync_time_vtime2unix(dtstart, 0);
+		dtstarted = osync_time_vtime2unix(dtstart, 0, &error);
 
 		dtstarted += duration;
-		runtime = osync_time_unix2vtime(&dtstarted);
+		runtime = osync_time_unix2vtime(&dtstarted, &error);
 
 		if (!osync_time_isutc(dtstart)) {
 			osync_trace(TRACE_INTERNAL, "WARNNING: timestamp is not UTC - converting reminder to localtime");
 			char *utc_runtime = runtime;
-			runtime = osync_time_vtime2localtime(utc_runtime, 0);
+			runtime = osync_time_vtime2localtime(utc_runtime, 0, &error);
 			g_free(utc_runtime);
 		}
 
@@ -347,6 +348,14 @@ VFormatAttribute *handle_xml_vcal_alarm_attribute(VFormat *vevent, OSyncXMLField
 
 	vformat_add_attribute(vevent, attr);
 
+	/* Check for any time-related error before returning */
+	if( error != NULL ) {
+		osync_trace(TRACE_INTERNAL, "Error (time-related function failed): %s",
+			osync_error_print(&error));
+		osync_error_unref(&error);
+		return NULL;
+	}
+
 	return attr;
 }
 /* END: xml -> vcalendar10 only attributes */

[Opensync-devel] Porting instructions for new Capabilities ??

[Henrik /K. <kaa...@us...>]

Dear OpenSync developers,

It is GREAT to see progress towards 0.40. Thanks a lot!

I was wondering if there are any porting instructions for the new way of 
handling capabilities...

In mozilla-sync
http://opensync.org/browser/plugins/mozilla-sync/trunk/src/mozilla-sync.cpp
I have calls to osync_capability_new (line 911), but the API seems to 
have changed...

Any hints on how to fix this?

/Henrik

[Opensync-devel] Ticket 1078 - Remove pendingLimit from OSyncQueue

[Henrik /K. <kaa...@us...>]

Dear all,

Are there any progress / comments / plans on ticket 1078?
See also comments on the mailinglist regarding
"Remove pendingLimit from OSyncQueue".

As far as I can see, this problem prevents any sync with SyncML devices,
as the SyncML protocol may have several changes in one message,
which I believe OpenSync cannot handle now...

/Henrik

[Opensync-devel] [trunk] osync_plugin_env_register_plugin() and osync_plugin_env_register_*() API changes

[Daniel G. <go...@b1...>]

Hi,

to make the 0.40-API more future-proof and avoid unnecessary breaks once we
freeze following change was made, which affects all sync and format plugins:

http://opensync.org/changeset/5772

Porting instruction:


Following function got additionally as last Parameter OSyncError** and the return
value got changed from void to osync_bool:

osync_format_env_register_objformat
osync_format_env_register_converter
osync_format_env_register_caps_converter
osync_format_env_register_merger

osync_plugin_env_register_plugin

If the function return FALSE, check the OSyncError** struct for any error.

Reference Port: http://opensync.org/changeset/5778


This API break was part of the API-cleanup-sprint:
http://opensync.org/ticket/1087#comment:36

Best Regards,
Daniel


-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

[Opensync-devel] [trunk] API: Error handling for osync_xmlfield_{add, set}_key and osync_xmlfield_sort

[Daniel G. <go...@b1...>]

Hi,

to make OSyncXMLField API more stable for the 0.40 soft-freeze following 
function got an OSyncError** added to their parameter list:

    * osync_xmlfield_add_key_value
    * osync_xmlfield_set_key_value
    * osync_xmlfield_sort 

Additionally the return type got changed from void to osync_bool. On FALSE 
check for any error in the OSyncError** struct.

This affects very likely most format plugins which provide conversion 
functions to the XMLFormat.


Porting instruction: add an OSyncError** to the function call and check the 
return value and handle any error.


Reference Port: http://opensync.org/changeset/5771
(Incomplete port, no complete error handling - see FIXME_ interfaces)

Changeset: http://opensync.org/changeset/5769

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

[Opensync-devel] Preparing for OpenSync API 0.40 soft-freeze

[Daniel G. <go...@b1...>]

Hi,

could you all double-check the public interfaces of the OpenSync trunk API, if 
they fit your needs for you application/plugin ... (those which got exported 
by the OSYNC_EXPORT macro)

I plan to _soft_ freeze thursday evening/night (CEST) the OpenSync API and do 
a quick accepteance test with various "hot-requested" plugins ... and port 
those which aren't yet ported. If you need assistance porting - please drop a 
mail on opensync-devel mailing list.

By "soft freeze" i plan to accept API-breaking changes after 0.39 which meets 
following criteria:

 - (only) critical bugfix


 - not for additional feature or enhancemnet
 - not cosmetic API cleanup


JFYI, there is only one ticket left for the 0.39 milestone which is waiting 
for validation if we have proper error-handling for all public Interfaces.

Best Regards,
Daniel


-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

[Opensync-devel] [trunk] osync_plugin_config_load_file API change: schemadir parameter

[Daniel G. <go...@b1...>]

Hi,

here is a (very simple) API change before soft-freezing the OpenSync 0.40-API.

The "const char *schemadir" parameter got dropped from the signature of function
osync_plugin_file_load(). Since this primarily used by unit-testing (internally)
this interface got dropped. OpenSync internal API provides for unit-testing the
newly added function osync_plugin_config_set_schemadir()

-OSYNC_EXPORT osync_bool osync_plugin_config_file_load(OSyncPluginConfig *config, const char *path, const char *schemadir, OSyncError **error);
+OSYNC_EXPORT osync_bool osync_plugin_config_file_load(OSyncPluginConfig *config, const char *path, OSyncError **error);


This was a left over of ticket #1013 (see comment 5) which breaks the trunk API.

Porting instruction for OpenSync Application (plugins are not affected):

 - just drop the parameter from this function call
 - all application (expect opensync unittests) should have called
   this function with schemadir parameter NULL anyway ...


Commit: http://opensync.org/changeset/5765

Best Regards,
Daniel

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] [PATCH] first try porting irmc-sync to latest API

[Volker S. <vo...@sc...>]

Hi Daniel,

i created a patch for the libopensync source code that causes the undefined symbol error.
The patch is attached as a text file on this mail.
After i defined the osync_objtype_sink_get_slowsync method i changed a function call in the irmc-sync
plugin and now it gets listed by "osyncplugin --pluginlist".

I havent tested if the module works correct.

Best Regards,

Volker

----- Originalnachricht -----
Von: Daniel Gollub <go...@b1...>
Gesendet: Sam, 9/5/2009 12:19pm
An: Volker Schreiner <vo...@sc...>
Cc: ope...@li...
Betreff: Re: [PATCH] first try porting irmc-sync to latest API

Hi Volker,


just checked your latest irmc-sync changes [1]. Regarding the issue that irmc-sync
get not listed - try this:

dgollub@marvin:~> export OSYNC_TRACE=/tmp/osync_trace/
dgollub@marvin:~> rm /tmp/osync_trace/*; osynctool --listplugins
ERROR: Unable to open module /home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: 
/home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: undefined symbol: osync_objtype_sink_get_slowsync
EXIT_ERROR: osync_module_load: Unable to open module /home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: 
/home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: undefined symbol: osync_objtype_sink_get_slowsync
Available plugins:
syncml-http-server
syncml-http-client
syncml-obex-client
file-sync
evo2-sync
dgollub@marvin:~> 


If you enable tracing by exporting OSYNC_TRACE every osync_trace(TRACE_ERROR*
call gets printed on stderr. Usually symbols are missing which avoid that the
plugin can be loaded. In this case you need to drop the use of

osync_objtype_sink_get_slowsync

AFAIK the plugin functions like get_changes() or so get called in thier
parameter lits with the information if a slowsync is requested or not. So
you can use this parameter instead of calling osync_objtype_sink_get_slowsync.

Check the file-sync plugin how this is done.


[1] http://opensync.org/changeset/5748


Best Regards,
Daniel

[...]

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] [PATCH] first try porting irmc-sync to latest API

[Daniel G. <go...@b1...>]

Hi Volker,


just checked your latest irmc-sync changes [1]. Regarding the issue that irmc-sync
get not listed - try this:

dgollub@marvin:~> export OSYNC_TRACE=/tmp/osync_trace/
dgollub@marvin:~> rm /tmp/osync_trace/*; osynctool --listplugins
ERROR: Unable to open module /home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: 
/home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: undefined symbol: osync_objtype_sink_get_slowsync
EXIT_ERROR: osync_module_load: Unable to open module /home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: 
/home/dgollub/build/OpenSync/lib/libopensync1/plugins/irmc-sync.so: undefined symbol: osync_objtype_sink_get_slowsync
Available plugins:
syncml-http-server
syncml-http-client
syncml-obex-client
file-sync
evo2-sync
dgollub@marvin:~> 


If you enable tracing by exporting OSYNC_TRACE every osync_trace(TRACE_ERROR*
call gets printed on stderr. Usually symbols are missing which avoid that the
plugin can be loaded. In this case you need to drop the use of

osync_objtype_sink_get_slowsync

AFAIK the plugin functions like get_changes() or so get called in thier
parameter lits with the information if a slowsync is requested or not. So
you can use this parameter instead of calling osync_objtype_sink_get_slowsync.

Check the file-sync plugin how this is done.


[1] http://opensync.org/changeset/5748


Best Regards,
Daniel

[...]

-- 
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D

Re: [Opensync-devel] [OpenSync 0.38] Need help getting File<=>SyncML (Google) to work

[numlock <wor...@gm...>]

Just to keep any interested people informed:

Daniel Gollub and I have been trying a few things concerning syncml with
google. We already know syncml-ds-tool works, but the opensync syncml plugin
doesn't work yet (even with latest trunk as of 2009-09-03).

When I (and/or Daniel) can get a working syncml to/from google, I will post
some update here. But it's clear that the latest SVN version will be a
requirement in order to do that synchronization.

Everyone, please feel free to answer if you're interested or if you had more
success than us already :-)
-- 
View this message in context: http://www.nabble.com/-OpenSync-0.38--Need-help-getting-File%3C%3D%3ESyncML-%28Google%29-to-work-tp25273314p25279852.html
Sent from the Opensync - Dev mailing list archive at Nabble.com.