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

Re: [Opensync-devel] wrong tagging

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

Daniel Gollub wrote:
> On Friday 06 November 2009 05:00:01 pm Michael Bell wrote:

> Michael, i already asked this on an OpenSync ticket, do you want to have the 
> same post-commit hook installed in libsyncml and libwbxml2 Subversion?
> The hook gets active as soon you copy a direcotry into */tags/$ ... the commit 
> takes a bit longer since on the subvesrion hosts an entire checkout of the tag 
> needs to be done to modify all externals properties ...
> 
> Check: http://people.b1-systems.de/~gollub/pin-external-on-tag.sh

I use another tagging "technology". I just use tar and not svn cp. So
sorry for my ignorance and no, actually I don't want this hook.

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

Re: [Opensync-devel] osync_archive_save_ignored_conflict()

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

On Sunday 08 November 2009 05:14:23 pm Daniel Gollub wrote:
> I guess it should look like this:
> 
> 
> ----8<---
> BEGIN TRANSACTION;
> CREATE TABLE tbl_changelog (objtype VARCHAR(64) NOT NULL, memberid INTEGER
>  NOT NULL, mappingid INTEGER NOT NULL, changetype INTEGER NOT NULL, PRIMARY
>  KEY (objtype, memberid,  mappingid) );
> INSERT INTO "tbl_changelog" VALUES('contact',1,4,4);
> INSERT INTO "tbl_changelog" VALUES('contact',2,4,4);
> INSERT INTO "tbl_changelog" VALUES('contact',1,6,4);
> INSERT INTO "tbl_changelog" VALUES('contact',2,6,3);
> COMMIT;
> ---->8---
> 

Find attachtd a proof of concept patch which is implementing this ...

--

 archive/opensync_archive.c                 |   31 +++++++++++++++--------------
 archive/opensync_archive_internals.h       |    8 ++++---
 engine/opensync_mapping_engine.c           |   16 ++++++++++++++
 engine/opensync_mapping_engine_internals.h |    1 
 engine/opensync_obj_engine.c               |   12 +++++++----
 mapping/opensync_mapping_entry_internals.h |    2 +
 6 files changed, 48 insertions(+), 22 deletions(-)

---


Index: opensync/mapping/opensync_mapping_entry_internals.h
===================================================================
--- opensync/mapping/opensync_mapping_entry_internals.h	(revision 5920)
+++ opensync/mapping/opensync_mapping_entry_internals.h	(working copy)
@@ -47,4 +47,6 @@
 
 /*@}*/
 
+long long int osync_mapping_entry_get_member_id(OSyncMappingEntry *entry);
+
 #endif /*OPENSYNC_MAPPING_ENTRY_INTERNALS_H_*/
Index: opensync/archive/opensync_archive.c
===================================================================
--- opensync/archive/opensync_archive.c	(revision 5926)
+++ opensync/archive/opensync_archive.c	(working copy)
@@ -94,7 +94,7 @@
 		return TRUE;
 	}
 
-	query = "CREATE TABLE tbl_changelog (objtype VARCHAR(64), id INTEGER, entryid INTEGER, changetype INTEGER, PRIMARY KEY (objtype, id) )";
+	query = "CREATE TABLE tbl_changelog (objtype VARCHAR(64) NOT NULL, memberid INTEGER NOT NULL, mappingid INTEGER NOT NULL, changetype INTEGER NOT NULL, PRIMARY KEY 
(objtype, memberid, mappingid) )";
 	if (!osync_db_query(db, query, error)) {
 		goto error;
 	}
@@ -478,26 +478,27 @@
 	return FALSE;
 }
 
-osync_bool osync_archive_load_ignored_conflicts(OSyncArchive *archive, const char *objtype, OSyncList **ids, OSyncList **changetypes, OSyncError **error)
+osync_bool osync_archive_load_ignored_conflicts(OSyncArchive *archive, const char *objtype, OSyncList **memberids, OSyncList **mappingids, OSyncList **changetypes, 
OSyncError **error)
 {
 	OSyncList *result = NULL, *row = NULL, *column = NULL;
 	char *query = NULL;
 	char *escaped_objtype = NULL;
-	long long int id = 0;
+	long long int mappingid = 0, memberid = 0;
 	int changetype = 0;
 
-	osync_trace(TRACE_ENTRY, "%s(%p, %s, %p, %p)", __func__, archive, objtype, ids, error);
+	osync_trace(TRACE_ENTRY, "%s(%p, %s, %p, %p)", __func__, archive, objtype, mappingids, error);
 
 	osync_assert(archive);
 	osync_assert(objtype);
-	osync_assert(ids);
+	osync_assert(memberids);
+	osync_assert(mappingids);
 	osync_assert(changetypes);
 
 	if (!osync_archive_create_changelog(archive->db, objtype, error))
 		goto error;
 
 	escaped_objtype = osync_db_sql_escape(objtype);
-	query = osync_strdup_printf("SELECT entryid, changetype FROM tbl_changelog WHERE objtype='%s' ORDER BY id", escaped_objtype);
+	query = osync_strdup_printf("SELECT memberid, mappingid, changetype FROM tbl_changelog WHERE objtype='%s' ORDER BY mappingid", escaped_objtype);
 	osync_free(escaped_objtype);
 	escaped_objtype = NULL;
 	result = osync_db_query_table(archive->db, query, error);
@@ -511,13 +512,15 @@
 	for (row = result; row; row = row->next) { 
 		column = row->data;
 
-		id = g_ascii_strtoull(osync_list_nth_data(column, 0), NULL, 0);
-		changetype = atoi(osync_list_nth_data(column, 1));
+		memberid = g_ascii_strtoull(osync_list_nth_data(column, 0), NULL, 0);
+		mappingid = atoi(osync_list_nth_data(column, 1));
+		changetype = atoi(osync_list_nth_data(column, 2));
 		
-		*ids = osync_list_append((*ids), GINT_TO_POINTER((int)id));
+		*memberids = osync_list_append((*memberids), GINT_TO_POINTER((int)memberid));
+		*mappingids = osync_list_append((*mappingids), GINT_TO_POINTER((int)mappingid));
 		*changetypes = osync_list_append((*changetypes), GINT_TO_POINTER((int)changetype));
 		
-		osync_trace(TRACE_INTERNAL, "Loaded ignored mapping with entryid %lli", id);
+		osync_trace(TRACE_INTERNAL, "Loaded ignored mapping with mappingid %lli", mappingid);
 	}
 
 	osync_db_free_list(result);	
@@ -529,11 +532,11 @@
 	return FALSE;	
 }
 
-osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const char *objtype, long long int id, OSyncChangeType changetype, OSyncError **error)
+osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const char *objtype, long long int memberid, long long int mappingid, OSyncChangeType changetype, 
OSyncError **error)
 {
 	char *query = NULL;
 	char *escaped_objtype = NULL;
-	osync_trace(TRACE_ENTRY, "%s(%p, %s, %lli, %p)", __func__, archive, objtype, id, error);
+	osync_trace(TRACE_ENTRY, "%s(%p, %s, %lli, %lli, %p)", __func__, archive, objtype, memberid, mappingid, error);
 
 	osync_assert(archive);
 	osync_assert(objtype);
@@ -542,7 +545,7 @@
 		goto error;
 	
 	escaped_objtype = osync_db_sql_escape(objtype);
-	query = osync_strdup_printf("INSERT INTO tbl_changelog (objtype, entryid, changetype) VALUES('%s', '%lli', '%i')", escaped_objtype, id, changetype);
+	query = osync_strdup_printf("INSERT INTO tbl_changelog (objtype, memberid, mappingid, changetype) VALUES('%s', '%lli', '%lli', '%i')", escaped_objtype, memberid, 
mappingid, changetype);
 	osync_free(escaped_objtype);
 	escaped_objtype = NULL;
 	
@@ -553,7 +556,7 @@
 
 	osync_free(query);
 	
-	osync_trace(TRACE_EXIT, "%s: %lli", __func__, id);
+	osync_trace(TRACE_EXIT, "%s: %lli", __func__, mappingid);
 	return TRUE;
 	
  error:
Index: opensync/archive/opensync_archive_internals.h
===================================================================
--- opensync/archive/opensync_archive_internals.h	(revision 5926)
+++ opensync/archive/opensync_archive_internals.h	(working copy)
@@ -136,24 +136,26 @@
  *
  * @param archive The group archive
  * @param objtype Requested object type 
- * @param mappingsids List to store the archive (database) ids of each entry
+ * @param memberids List to store the member ids of each entry
+ * @param mappingsids List to store the mapping ids of each entry
  * @param changetypes List to store the changetypes for each entry
  * @param error Pointer to an error struct
  * @return TRUE on when all changes successfully loaded otherwise FALSE
  */
-osync_bool osync_archive_load_ignored_conflicts(OSyncArchive *archive, const char *objtype, OSyncList **mappingsids, OSyncList **changetypes, OSyncError **error);
+osync_bool osync_archive_load_ignored_conflicts(OSyncArchive *archive, const char *objtype, OSyncList **memberids, OSyncList **mappingsids, OSyncList **changetypes, 
OSyncError **error);
 
 /**
  * @brief Saves an entry in the ignored conflict list.
  *
  * @param archive The group archive
  * @param objtype Reported object type of entry
+ * @param memberid Member ID of entry 
  * @param mappingid Mapping Entry ID of entry 
  * @param changetype Changetype of entry 
  * @param error Pointer to an error struct
  * @return Returns TRUE on success, FALSE otherwise 
  */
-osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const char *objtype, long long int mappingid, OSyncChangeType changetype, OSyncError **error);
+osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const char *objtype, long long int memberid, long long int mappingid, OSyncChangeType changetype, 
OSyncError **error);
 
 /**
  * @brief Deletes all ignored conflict entries of the changelog with the objtype.
Index: opensync/engine/opensync_mapping_engine.c
===================================================================
--- opensync/engine/opensync_mapping_engine.c	(revision 5920)
+++ opensync/engine/opensync_mapping_engine.c	(working copy)
@@ -126,6 +126,20 @@
 	}
 }
 
+OSyncMappingEntryEngine *osync_mapping_engine_find_entry_by_memberid(OSyncMappingEngine *engine, long long int memberid)
+{
+	OSyncList *e;
+	for (e = engine->entries; e; e = e->next) {
+		OSyncMappingEntryEngine *entry = e->data;
+
+		if (osync_mapping_entry_get_member_id(entry->entry) == memberid)
+			return entry;
+	}
+	
+	return NULL;
+}
+
+
 static OSyncMappingEntryEngine *_osync_mapping_engine_find_entry(OSyncMappingEngine *engine, OSyncChange *change)
 {
 	OSyncList *e;
@@ -620,7 +634,7 @@
 
 	for (c = engine->entries; c; c = c->next) {
 		OSyncMappingEntryEngine *entry = c->data;
-		osync_archive_save_ignored_conflict(archive, objtype, id, osync_change_get_changetype(entry->change), error);
+		osync_archive_save_ignored_conflict(archive, objtype, osync_mapping_entry_get_member_id(entry->entry), id, osync_change_get_changetype(entry->change), error);
 	}
 
 	osync_status_update_mapping(engine->parent->parent, engine, OSYNC_ENGINE_MAPPING_EVENT_SOLVED, NULL);
Index: opensync/engine/opensync_obj_engine.c
===================================================================
--- opensync/engine/opensync_obj_engine.c	(revision 5938)
+++ opensync/engine/opensync_obj_engine.c	(working copy)
@@ -767,8 +767,8 @@
 
 static osync_bool _inject_changelog_entries(OSyncObjEngine *engine, OSyncError **error) {
 	OSyncList *ids = NULL;
-	OSyncList *changetypes = NULL;
-	OSyncList *j = NULL, *t = NULL;
+	OSyncList *changetypes = NULL, *memberids = NULL;
+	OSyncList *j = NULL, *t = NULL, *mid = NULL;
 
 	osync_trace(TRACE_ENTRY, "%s(%p)", __func__, engine);
 
@@ -776,12 +776,13 @@
 	osync_assert(engine->archive);
 	osync_assert(engine->objtype);
 	
-	if (!osync_archive_load_ignored_conflicts(engine->archive, engine->objtype, &ids, &changetypes, error)) {
+	if (!osync_archive_load_ignored_conflicts(engine->archive, engine->objtype, &memberids, &ids, &changetypes, error)) {
 		osync_trace(TRACE_EXIT_ERROR, "%s: %s", __func__, osync_error_print(error));
 		return FALSE;
 	}
 
 	t = changetypes;
+	mid = memberids;
 	for (j = ids; j; j = j->next) {
 		long long int id = (long long int)GPOINTER_TO_INT(j->data);
 
@@ -793,8 +794,10 @@
 
 			if (mapping_engine->mapping == ignored_mapping) {
 				OSyncList *m;
+
 				for (m = mapping_engine->entries; m; m = m->next) {
-					OSyncMappingEntryEngine *entry = m->data;
+					long long int memberid = (long long int)GPOINTER_TO_INT(mid->data);
+					OSyncMappingEntryEngine *entry = osync_mapping_engine_find_entry_by_memberid(mapping_engine, memberid);
 					OSyncChangeType changetype = (OSyncChangeType) t->data;
 					OSyncChange *ignored_change = osync_change_new(error);
 					OSyncObjFormat *dummyformat = NULL;
@@ -817,6 +820,7 @@
 		}
 
 		t = t->next;
+		mid = mid->next;
 	}
 
 	osync_list_free(ids);
Index: opensync/engine/opensync_mapping_engine_internals.h
===================================================================
--- opensync/engine/opensync_mapping_engine_internals.h	(revision 5920)
+++ opensync/engine/opensync_mapping_engine_internals.h	(working copy)
@@ -65,6 +65,7 @@
 osync_bool osync_mapping_engine_check_conflict(OSyncMappingEngine *engine);
 
 OSyncMappingEntryEngine *osync_mapping_engine_get_entry(OSyncMappingEngine *engine, OSyncSinkEngine *sinkengine);
+OSyncMappingEntryEngine *osync_mapping_engine_find_entry_by_memberid(OSyncMappingEngine *engine, long long int memberid);
 
 OSYNC_TEST_EXPORT unsigned int osync_mapping_engine_num_changes(OSyncMappingEngine *engine);
 


-- 
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] osync_archive_save_ignored_conflict()

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

On Saturday 07 November 2009 12:58:38 am Chris Frey wrote:
> Hi,
> 
> In the opensync_archive_internals.h header, _save_ignored_conflict()
> is documented as such:
> 
> /**
>  * @brief Saves an entry in the ignored conflict list.
>  *
>  * @param archive The group archive
>  * @param objtype Reported object type of entry
>  * @param mappingid Mapping Entry ID of entry

That's correct.

>  * @param changetype Changetype of entry
>  * @param error Pointer to an error struct
>  * @return Returns TRUE on success, FALSE otherwise
>  */
> osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const
>  char *objtype, long long int mappingid, OSyncChangeType changetype,
>  OSyncError **error);
> 
> 
> In opensync_archive.c, it is implemented like this:
> 
> osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const
>  char *objtype, long long int id, OSyncChangeType changetype, OSyncError
>  **error) {
> [...]

maybe we should sync this up with the other declaration and call it "mappingid".

> 
>         query = osync_strdup_printf("INSERT INTO tbl_changelog (objtype,
>  entryid, changetype) VALUES('%s', '%lli', '%i')", escaped_objtype, id,
>  changetype);

The tbl_changelog is indeed very confusing. There is one column left-over we
doesn't us at all: "id"

And the "entryid" is also very confusing.

> 
> ...
> 
> 
> Isn't the entryid field used for the archive id's themselves, and not the
> mapping ids?

Not quite sure which ID you mean for "archive id".

FYI, the tbl_changelog is only used for handling "ignored" conflicts ...
tbl_changes is used to store the "mappings".
tbl_archive stores only the entire entries of a change when merger/demerge
gets used.


While looking into this i found a bug in OpenSync which broke the support
of "ignore conflicts". Which is hopefully fixed now with r5950


Here is a dump of the tbl_changes and tbl_changelog, which contains two
conflicts which got ignored. (I used for that a group with two file-sync members)

----8<----
BEGIN TRANSACTION;
CREATE TABLE tbl_changes (objtype VARCHAR(64) NOT NULL, id INTEGER PRIMARY KEY AUTOINCREMENT, uid VARCHAR NOT NULL, memberid INTEGER NOT NULL, mappingid INTEGER NOT NULL, 
objengine VARCHAR(64) NOT NULL );
INSERT INTO "tbl_changes" VALUES('contact',67,'foo0',2,1,'contact');
INSERT INTO "tbl_changes" VALUES('contact',68,'foo3',2,2,'contact');
INSERT INTO "tbl_changes" VALUES('contact',69,'foo1',2,3,'contact');
INSERT INTO "tbl_changes" VALUES('contact',70,'test1.vcard',2,4,'contact');
INSERT INTO "tbl_changes" VALUES('contact',71,'foo5',2,5,'contact');
INSERT INTO "tbl_changes" VALUES('contact',72,'foo8',2,6,'contact');
INSERT INTO "tbl_changes" VALUES('contact',73,'foo4',2,7,'contact');
INSERT INTO "tbl_changes" VALUES('contact',74,'foo2',2,8,'contact');
INSERT INTO "tbl_changes" VALUES('contact',75,'foo6',2,9,'contact');
INSERT INTO "tbl_changes" VALUES('contact',76,'foo7',2,10,'contact');
INSERT INTO "tbl_changes" VALUES('contact',77,'foo9',2,11,'contact');
INSERT INTO "tbl_changes" VALUES('contact',78,'foo0',1,1,'contact');
INSERT INTO "tbl_changes" VALUES('contact',79,'foo3',1,2,'contact');
INSERT INTO "tbl_changes" VALUES('contact',80,'foo1',1,3,'contact');
INSERT INTO "tbl_changes" VALUES('contact',81,'test1.vcard',1,4,'contact');
INSERT INTO "tbl_changes" VALUES('contact',82,'foo5',1,5,'contact');
INSERT INTO "tbl_changes" VALUES('contact',84,'foo4',1,7,'contact');
INSERT INTO "tbl_changes" VALUES('contact',85,'foo2',1,8,'contact');
INSERT INTO "tbl_changes" VALUES('contact',86,'foo6',1,9,'contact');
INSERT INTO "tbl_changes" VALUES('contact',87,'foo7',1,10,'contact');
INSERT INTO "tbl_changes" VALUES('contact',88,'foo9',1,11,'contact');
COMMIT;
dgollub@marvin:~> sqlite3 .config/opensync/0.40/group1/archive.db ".dump tbl_changelog" 
BEGIN TRANSACTION;
CREATE TABLE tbl_changelog (objtype VARCHAR(64), id INTEGER, entryid INTEGER, changetype INTEGER, PRIMARY KEY (objtype, id) );
INSERT INTO "tbl_changelog" VALUES('contact',NULL,4,4);
INSERT INTO "tbl_changelog" VALUES('contact',NULL,4,4);
INSERT INTO "tbl_changelog" VALUES('contact',NULL,6,4);
INSERT INTO "tbl_changelog" VALUES('contact',NULL,6,3);
COMMIT;
---->8---


(changetypes: 3 == deleted, 4 == modified)

And indeed this looks pretty strange - 4 tbl_changelog for 2 mappings ...

The information is missing which member was sending which changetype ...

I guess it should look like this:


----8<---
BEGIN TRANSACTION;
CREATE TABLE tbl_changelog (objtype VARCHAR(64) NOT NULL, memberid INTEGER NOT NULL, mappingid INTEGER NOT NULL, changetype INTEGER NOT NULL, PRIMARY KEY (objtype, memberid, 
mappingid) );
INSERT INTO "tbl_changelog" VALUES('contact',1,4,4);
INSERT INTO "tbl_changelog" VALUES('contact',2,4,4);
INSERT INTO "tbl_changelog" VALUES('contact',1,6,4);
INSERT INTO "tbl_changelog" VALUES('contact',2,6,3);
COMMIT;
---->8---


Does this sound sane?
Does this address your question?

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] osync_archive_save_ignored_conflict()

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

Hi,

In the opensync_archive_internals.h header, _save_ignored_conflict()
is documented as such:

/**
 * @brief Saves an entry in the ignored conflict list.
 *
 * @param archive The group archive
 * @param objtype Reported object type of entry
 * @param mappingid Mapping Entry ID of entry 
 * @param changetype Changetype of entry 
 * @param error Pointer to an error struct
 * @return Returns TRUE on success, FALSE otherwise 
 */
osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const char *objtype, long long int mappingid, OSyncChangeType changetype, OSyncError **error);


In opensync_archive.c, it is implemented like this:

osync_bool osync_archive_save_ignored_conflict(OSyncArchive *archive, const char *objtype, long long int id, OSyncChangeType changetype, OSyncError **error)
{
[...]

        query = osync_strdup_printf("INSERT INTO tbl_changelog (objtype, entryid, changetype) VALUES('%s', '%lli', '%i')", escaped_objtype, id, changetype);

...


Isn't the entryid field used for the archive id's themselves, and not the
mapping ids?

Thanks,
- Chris

Re: [Opensync-devel] wrong tagging

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

On Friday 06 November 2009 05:00:01 pm Michael Bell wrote:
> I discovered during svn update that the cmake directory of released
> versions in osynctool/tags is a external link. This is a bug. If you
> release a source then all content of the release must be static.
> 
> I fixed this for libsyncml a while ago. It is just a question of a
> better documentation. I don't checked this for libopensync. I just
> discovered the issue two minutes ago.
> 

This is fixed for all newly created tags. A post-commit hook will pin 
externals to the revision when it got tagged.


Just did a test-tag to demonstrate the post-commit hook:

http://opensync.org/changeset/5947
http://opensync.org/changeset/5948 (commit by the hook to pin the 
svn:Externals property)

Michael, i already asked this on an OpenSync ticket, do you want to have the 
same post-commit hook installed in libsyncml and libwbxml2 Subversion?
The hook gets active as soon you copy a direcotry into */tags/$ ... the commit 
takes a bit longer since on the subvesrion hosts an entire checkout of the tag 
needs to be done to modify all externals properties ...

Check: http://people.b1-systems.de/~gollub/pin-external-on-tag.sh

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] wrong tagging

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

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

Hi,

I discovered during svn update that the cmake directory of released
versions in osynctool/tags is a external link. This is a bug. If you
release a source then all content of the release must be static.

I fixed this for libsyncml a while ago. It is just a question of a
better documentation. I don't checked this for libopensync. I just
discovered the issue two minutes ago.

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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr0R/0ACgkQ2L0ZGCAwWqutLACgvem58cxp2OAvWVvyExZ30M8N
5rsAnioLjKYLiHVTAaanxWfjR25fICti
=Cs3Y
-----END PGP SIGNATURE-----

Re: [Opensync-devel] Fixed SyncML plugin commit limitation and reenabled pending limit in OpenSync

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

On Friday 06 November 2009 12:46:09 pm Michael Bell wrote:
> Does OpenSync trunk works?

Yes.

Only the merging and capabilities stuff is not completed.
And the XMLFormat and vformat plugin still lacking some fields ...

> 
> If yes, then I would migrate the SyncML plugin to libsyncml trunk on the
> weekend. Additionally I would like to branch the actual code to have a
> maintainable libsyncml 0.5.x port. My problem is that I don't know where
> to place such a branch.

I'll take care about that...
We already planned to have a trunk/branches/tags direcotry hierachy for 
plugins. Will do that for SyncML plugin now.

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] Fixed SyncML plugin commit limitation and reenabled pending limit in OpenSync

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

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

Hi Daniel,

Daniel Gollub wrote:

> The SyncML plugin is now able to write more then 4 entries without exceeding 
> the pending limit and without deadlocking. Just committed approx. 50 entries 
> at once to my test mobile (SyncML Data-Sync server implementation only 
> tested):
> http://opensync.org/changeset/5941

Does OpenSync trunk works?

If yes, then I would migrate the SyncML plugin to libsyncml trunk on the
weekend. Additionally I would like to branch the actual code to have a
maintainable libsyncml 0.5.x port. My problem is that I don't know where
to place such a branch.

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.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAkr0DH4ACgkQ2L0ZGCAwWqtcHACdHsfzXH0vV7CP6qSu+HrlS3tb
GLUAmOcG43lotXQI4ofFTE4EmwlHg5o=
=8Z+w
-----END PGP SIGNATURE-----

[Opensync-devel] Fixed SyncML plugin commit limitation and reenabled pending limit in OpenSync (was: Re: [trunk] Introduced osync_context_report_uid_update() in sync_done() phase)

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

Hi,

On Thursday 05 November 2009 05:40:29 pm Daniel Gollub wrote:
[...]
> This issue solves a well known problem of the SyncML plugin and the
>  OpenSync IPC by deadlocking after 4 entries in a row get written to the
>  SyncML-peer. This is not yet implemented in the SyncML plugin.
[...]

just reenabled the pending limit in OpenSync:
http://opensync.org/changeset/5942


http://opensync.org/changeset/5858 was there a ticket for this change?

The SyncML plugin is now able to write more then 4 entries without exceeding 
the pending limit and without deadlocking. Just committed approx. 50 entries 
at once to my test mobile (SyncML Data-Sync server implementation only 
tested):
http://opensync.org/changeset/5941

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] Introduced osync_context_report_uid_update() in sync_done() phase

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

Hi,

just implemented the osync_context_report_uid_update() function for sync-
plugins.

This functions allows to support protocols or synchronization-interfaces which 
replace the initial UID after the change got comitted/written, and report them 
after all changes got written.

There are already lots of plugins which overwrite the UID of an OSyncChange 
during the commit() function. But this works only for protocols/interfaces 
which provide the new UID immediately after the single write of a change.

Protocols like SyncML for example, maybe there are others as well, which 
provide the information about a "mapping update" (or changed UIDs of just 
written entries) after all changes got written.

Now we can handle this flawless with the introduction of 
osync_context_report_uid_update().

Plugins can now call this function in the sync_done() function and report all 
updated UIDs, by just providing the old-UID and the new-UID. OpenSync will 
take care the mapping of the right entries doesn't get lost. OpenSync also 
updates this information inside the hashtable - if used.

The interface looks like this:

void osync_context_report_uid_update(OSyncContext *ctx,
                                     const char *olduid, const char *newuid);




This issue solves a well known problem of the SyncML plugin and the OpenSync 
IPC by deadlocking after 4 entries in a row get written to the SyncML-peer.
This is not yet implemented in the SyncML plugin.

For more information see http://opensync.org/ticket/1161


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] osync_engine_mapping_ignore_conflict and osync_bool osync_engine_mapping_use_latest

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

On Tuesday 03 November 2009 01:18:24 pm Henrik /KaarPoSoft wrote:
> See also http://opensync.org/ticket/1185
> 
> Can anybody explain what a plugin has to do in order to support those 
> two conflict solutions?
> 

I replied in the ticket-system.

Quick Summary:

To support conflict handler "ignore": plugins need to implement the plugin 
sink function: "read" (!= get_changes)

To support conflict handler use_latest .. the format plugins need to implement 
the "revision" function.

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] osync_engine_mapping_ignore_conflict and osync_bool osync_engine_mapping_use_latest

[Henrik /K. <he...@ka...>]

Dear all,

It seems that osync_engine_mapping_ignore_conflict and osync_bool 
osync_engine_mapping_use_latest can only be used if the plugin works in 
a certain way.

See also http://opensync.org/ticket/1185

Can anybody explain what a plugin has to do in order to support those 
two conflict solutions?

Thanks in advance,
Henrik

Re: [Opensync-devel] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

On Monday 02 November 2009 12:25:07 am Graham Cobb wrote:
> I have checked in my changes for the external plugin config file (r5906).  

Thanks a lot!

> Things still left to do (most important first):
> 
> 1) Unit tests for the new code

Created a ticket for that:
http://opensync.org/ticket/1184

> 
> 2) ExternalCommand support.

Implemented:
http://opensync.org/changeset/5914


> 
> 3) Validation against XSD.

This is next on my TODO list ...

> 
> As I mentioned, I am travelling on business for the next few weeks.  I 
> probably won't get much time to look at this (or the timeout stuff) while
>  I  am away.
> 

Ok, i'll concentrate on the timeout stuff once the extenral stuff is completed 
(very likely after the XSD got written). I need to introduce some more 
interface for mapping update ... once this is done we can reenable the IPC 
pendingLimit ... see http://opensync.org/ticket/1161

Thanks for your core contribution! ;)
Wish you a safe trip!

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] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

Daniel,

I have checked in my changes for the external plugin config file (r5906).  
Things still left to do (most important first):

1) Unit tests for the new code

2) ExternalCommand support.

3) Validation against XSD.

As I mentioned, I am travelling on business for the next few weeks.  I 
probably won't get much time to look at this (or the timeout stuff) while I 
am away.

Graham

Re: [Opensync-devel] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

On Sunday 01 November 2009 13:32:57 Daniel Gollub wrote:
> On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> > 1) When I run the unittests, 17 of them fail.  I don't think any of them
> >  are  related to these changes but is that expected at the moment?
>
> No, actually they should fail.
>
> Could you run: "make Experimental" so the testing resutls get uploaded to
> the CDash dashboard .. so we can have a look on the logs?

I reverted my changes and re-ran the tests.  I got 18 failures.  I ran make 
Experimental but I haven't had time to investigate the failures.  I note that 
most of them failed with:

/home/Linux/opensync/trunk/tests/mock-plugin/mock_sync.c:241:E:mock_write: 
Assertion "!g_file_test(filename, G_FILE_TEST_EXISTS)" failed

Any ideas?

Given that the same errors occur with or without my changes I am going to 
check in my changes anyway.

By the way, I normally only run "make test" as I sort of presumed you didn't 
want the dashboard full of random tests of developers while they are 
debugging their code.  What are the guidelines for when we should run make 
Experimental?

I find the CTest verbose logs fairly uninformative in many cases.  Is there 
any way to use gdb to step through the test case code (and/or to debug the 
OpenSync code)?  

Graham

Re: [Opensync-devel] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

Just a quick email reply for now -- hopefully I will get some time to actually 
work on this later today.  

On Sunday 01 November 2009 13:32:57 Daniel Gollub wrote:
> On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> > I have a first cut of the external plugin config file ready to check in
> > (http://opensync.pastebin.com/m38d98a95).
>
> Thanks, will review your patch ASAP!

Thanks for your feedback, including in your other emails.

> > 1) When I run the unittests, 17 of them fail.  I don't think any of them
> >  are  related to these changes but is that expected at the moment?

> > If it is not expected I will have to do some more checking.
>
> Would be great if you could check whats going wrong there ...
> Those tests also fail if you revert your changes - right?

That is the first step in the "more checking" :-)  I will look into this later 
this evening.

> > 2) I have created an example external plugin config file in
> > docs/examples/plugins/src.  Can the existing CMake macros be used to get
> >  that  file installed into the plugin directory (which is where I am
> >  looking for it -- I look for .xml files first, then .so files)?  I
> > haven't tried it but I assume the macros like OPENSYNC_PLUGIN_INSTALL
> > expect a .so file.

> I'll introduce a cmake macro called "OPENSYNC_EXTERNAL_PLUGIN_INSTALL" ...

Thanks, I will use that.

> > 3) The XML format includes <ExternalCommand> but I currently ignore
> >  it.  My  plan is that this should be saved in the plugin structure and
> >  could be used as a default for the config option that Henrik is adding.
>
> Ok, fine with me.

I saw your other email on this.  I will try to get to this today but may not 
have time.  I want to concentrate on getting the basic code working and 
tested.

> > 4) If the .xml and the .so are both present, they both get loaded and two
> > plugins exist with the same name.  I thought of adding error checking to
> > osync_plugin_set_name to fail if a plugin of the same name is already
> >  loaded.   But I have just noticed that none of the osync_plugin_set_...
> >  calls have OSyncError parameters.  Should they?  This would be an API
> >  change (to a widely used API).

> Anyway, this is a different issue - independent of your planned changes ..
> which should get fixed at some point. I'll create for that a ticket ... in
> my opionoen it's not a blocker, since this could be avoided by distribution
> with sane packaging ;)

OK.  I am not going to worry about this at the moment.

From your other email:

> Is the drop of osync_module_unload() intended?

Yes, it is necessary.  The pseudo-plugin created by the new external plugin 
code has no module->module (it is NULL).  That seems reasonable to me as no 
module has been loaded.  The only place that gets upset by this is 
osync_module_unload() which asserts that module->module exists.  That also 
seems reasonable to me: you shouldn't be trying to unload a module if one was 
never loaded.

Fortunately, osync_module_unref() already unloads the module if this is the 
last reference and if module->module is non-null (i.e. a module was actually 
loaded).  So, it is never necessary to call osync_module_unload() 
explicitly -- it will be unloaded automatically when the last reference is 
dropped.

In fact, I would even argue it is a bug: the caller does not know that someone 
else does not hold a reference and the module should not be unloaded until 
the last reference is dropped.

So, yes it is deliberate.  The change to the comment was supposed to give a 
hint!

As for ignoring the error on loading the external plugin, you are right that I 
did it because that is the way the existing plugin code worked.  You are also 
right that we should probably be making the error visible somewhere other 
than the trace files and if we *really* want to ignore it we should be 
freeing the error struct.  I will add the FIXME.

You mention that you will write an XSD (thanks -- another thing I have never 
done!).  Should I validiate the XML file against the XSD before loading it?  
I noticed that some other code (can't remember what, offhand, maybe config 
file loading?) does that.

Graham

[Opensync-devel] mozilla-sync - now with OSYNC_START_TYPE_EXTERNAL

[Henrik /K. <he...@ka...>]

Until now, the mozilla-sync plugin has been running inside the OpenSync 
process, and accessing the mozilla data in a non-thread-safe way.

The mozilla-sync plugin is now replaced by a simple stub, running with 
OSYNC_START_TYPE_EXTERNAL

This means, that the bulk of the work is now done in the blueZync 
plugin, by calling thunderbird --mozilla-sync /path/to/pipe

The implementation is still not thread-safe, but with the threading 
capabilities of Thunderbird 3, it will be possible to make a thread-safe 
implementation for Thunderbird 3.

http://bluezync.svn.sourceforge.net/viewvc/bluezync?view=rev&revision=481
and
http://opensync.org/log/plugins/mozilla-sync/trunk/src?rev=5901**
implements this behaviour.

(However, it currently only works for Thunderbird address-books, not for 
sunbird and lightning. Also, it will not work with Debian ice*)

Build instructions:
http://bluezync.kaarposoft.dk/building.html

/Henrik

Re: [Opensync-devel] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> 3) The XML format includes <ExternalCommand> but I currently ignore
>  it.  My  plan is that this should be saved in the plugin structure and
>  could be used as a default for the config option that Henrik is adding.
> 

I reserved a place in the code where you could make use of the ExternalCommand 
form the XML EXternal Plugin file ...

See: 
http://opensync.org/changeset/5898/trunk/opensync/engine/opensync_engine.c

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] ExternalCommand in the plugin configuration file

[Henrik /K. <he...@ka...>]

Plugins of type OSYNC_START_TYPE_EXTERNAL needs to be able to spawn an 
external command to run the actual plugin code.

SVN -r 5896 allows a member to set an ExternalCommand in the plugin 
configuration file.
This command will be executed by the proxy to start up the external process.

The external_command should be a string in printf format, with one %s.
Before the command is executed, a variant of printf will be called
to replace the %s with the path to the plugin pipe.

Example:
<ExternalPlugin>
  <ExternalCommand>thunderbird -mozilla-sync %s</ExternalCommand>
</ExternalPlugin>

Added to public API:
osync_plugin_config_get_externalplugin
osync_plugin_config_set_externalplugin
osync_plugin_externalplugin_new
osync_plugin_externalplugin_unref
osync_plugin_externalplugin_ref
osync_plugin_externalplugin_get_external_command
osync_plugin_externalplugin_set_external_command
(as well as the changed format for the plugin configuration file)

Changed internal interface:
From
  osync_bool osync_client_proxy_spawn(OSyncClientProxy *proxy, 
OSyncStartType type, const char *path, OSyncError **error)
To
  osync_bool osync_client_proxy_spawn(OSyncClientProxy *proxy, 
OSyncStartType type, const char *path, const char* external_command, 
OSyncError **error)


/Henrik

Re: [Opensync-devel] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> I have a first cut of the external plugin config file ready to check in 
> (http://opensync.pastebin.com/m38d98a95).  But I have a couple of
>  questions:
> 

------8<-----
@@ -69,9 +71,8 @@
                        env->plugins = osync_list_remove(env->plugins, env-
>plugins->data);
                }

-               /* Unload all modules */
+               /* Unref (and so unload) all modules */
                while (env->modules) {
-                       osync_module_unload(env->modules->data);
                        osync_module_unref(env->modules->data);
                        env->modules = osync_list_remove(env->modules, env-
>modules->data);
                }
----->8----

Is the drop of osync_module_unload() intended?



---------8<----------
@@ -117,6 +119,31 @@
[...]
+               if (!osync_plugin_env_load_module_xml(env, filename, error)) {
+                       osync_trace(TRACE_ERROR, "Unable to load module: %s", 
osync_error_print(error));
+               }
+               
+               osync_free(filename);
[...]
---------->8--------------

You ignore the error, like it was done for the loading the shared-module
plugins - right? Or is there any specific reason for that?

We should place here (and for the same place for shared-modules loading) a
FIXME .. since we're leaking here a OSyncError-struct if an error get set.
And also problems of loading a plugin is not visible as long you don't look
into trace-files  ... but that shouldn't block to apply your patch. I'll
create a ticket for that issue ...


Beside that this looks pretty perfect to me. I'll write a XSD (XML-Schema)
for your XML file.

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] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

On Sunday 01 November 2009 01:39:24 am Graham Cobb wrote:
> I have a first cut of the external plugin config file ready to check in 
> (http://opensync.pastebin.com/m38d98a95).


Thanks, will review your patch ASAP!


> But I have a couple of
>  questions:
> 
> 1) When I run the unittests, 17 of them fail.  I don't think any of them
>  are  related to these changes but is that expected at the moment?

No, actually they should fail.

Could you run: "make Experimental" so the testing resutls get uploaded to the 
CDash dashboard .. so we can have a look on the logs?


http://opensync.org/testing/index.php?project=OpenSync



> 
> The following tests FAILED:
[...]


JFYI, you can also run those tests with:

ctest -V

-V makes things more verbose ...

If you only want to run specific tests you can use -R $regex to run only 
specifc tests - e.g.:

ctest -V -R sync_

Will run all tests including "sync_"

> 
> If it is not expected I will have to do some more checking.

Would be great if you could check whats going wrong there ...
Those tests also fail if you revert your changes - right?

> 
> 2) I have created an example external plugin config file in 
> docs/examples/plugins/src.  Can the existing CMake macros be used to get
>  that  file installed into the plugin directory (which is where I am
>  looking for it -- I look for .xml files first, then .so files)?  I haven't
>  tried it but I assume the macros like OPENSYNC_PLUGIN_INSTALL expect a .so
>  file.

OSYNC_PLUGIN_INSTALL is quite simple ... it doesn't check for *.so

-----8<----
## Install plugin
MACRO( OPENSYNC_PLUGIN_INSTALL _pluginName )
  INSTALL( TARGETS ${_pluginName} DESTINATION ${OPENSYNC_PLUGINDIR} )
ENDMACRO( OPENSYNC_PLUGIN_INSTALL )
---->8------

So you could point this to a .xml file ... but maybe we should introduce a new 
macro for such configuration file. Maybe one day we want to change the 
location of this kind config file .. so we just need to change the central 
macro, and don't have to fix all plugins. What do you think?

> 
> I really don't know CMake -- can anyone advise how to get my .xml file 
> installed into the plugin directory?

I'll introduce a cmake macro called "OPENSYNC_EXTERNAL_PLUGIN_INSTALL" ...


> 
> The new code seems to work but there are a few things that still need to
>  be  done:
> 
> 3) The XML format includes <ExternalCommand> but I currently ignore
>  it.  My  plan is that this should be saved in the plugin structure and
>  could be used as a default for the config option that Henrik is adding.

Ok, fine with me.

> 
> 4) If the .xml and the .so are both present, they both get loaded and two 
> plugins exist with the same name.  I thought of adding error checking to  
> osync_plugin_set_name to fail if a plugin of the same name is already
>  loaded.   But I have just noticed that none of the osync_plugin_set_...
>  calls have OSyncError parameters.  Should they?  This would be an API
>  change (to a widely used API).

Actually the file-name of a plugin doesn't have to be the name of the plugin 
in the Plugin Enviroment. e.g.: syncml.so spawns 4 plugins, non called 
"syncml".

But i see your point with osync_plugin_set_name() .. and having multiple 
plugins with the same name. This problem is already present ... even without 
your modification.

What we could do, without breaking the api to handle this:

We could let osync_plugin_env_load() fail if there are multiple plugins with 
the same name in the env->plugins list. Or we could let 
osync_plugin_env_register_plugin() fail ... but this function get called by 
the plugins any maybe not get handled by the plugin. We could do checks in 
both function to be sure ...

Anyway, this is a different issue - independent of your planned changes .. 
which should get fixed at some point. I'll create for that a ticket ... in my 
opionoen it's not a blocker, since this could be avoided by distribution with 
sane packaging ;)

> 
> 5) There is no unittest for this code yet.
> 
> I'm not sure if I will get time to work on this further on Sunday -- I
>  will  check it in by the end of Sunday.
> 

Ok, cool. Thanks for your contribution!

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] [RFC][PATCH] External command in plugin configuration file

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

On Saturday 31 October 2009 11:01:33 am Henrik /KaarPoSoft wrote:
> Following Daniel's checkin of the client and example code for external 
> plugin, here is a patch (on -r5895) which allows a member to set an 
> ExternalCommand in the plugin configuration file. This command will be 
> executed by the proxy to start up the external process.
> 
> Your comments would be most appreciated.
> 

One questions regarding the API:

osync_member_get_external_command()

Is there any reason to export this function to the public API? Our goal should 
be to have only a small number of public API interfaces .. so it's easier to 
maintain and to keep the API stable .. currently i don't see any reason to put 
this inside opensync_member.h

Instead i would suggest to move this into osync_member_internals.h and use 
OSYNC_TEST_EXPORT instead .. not OSYNC_EXPORT. So this function is still 
avaibale for the osync_engine.c code and for unittests...

Beside this the patch looks pretty good to me ...

JFYI, we have a unit test to avoid API breaks - if you add new public 
Interfaces you need to modifiy following file: trunk/opensync.sym

Just add by hand the function name - sorted. And test with:
ctest -R symbol -V

Currently it fails with your patch, due to missing entries:


-----8<----
332a333
> osync_member_get_external_command <------------- IGNORE this!
513a515
> osync_plugin_config_get_externalplugin
522a525
> osync_plugin_config_set_externalplugin
568a572,576
> osync_plugin_externalplugin_get_external_command
> osync_plugin_externalplugin_new
> osync_plugin_externalplugin_ref
> osync_plugin_externalplugin_set_external_command
> osync_plugin_externalplugin_unref
-- Process completed
***Failed 

0% tests passed, 1 tests failed out of 1

The following tests FAILED:
          1 - symbols (Failed)
------->8----

So you need to add follwing lines to opensync.sym:

osync_plugin_config_get_externalplugin
osync_plugin_config_set_externalplugin

osync_plugin_externalplugin_get_external_command
osync_plugin_externalplugin_new
osync_plugin_externalplugin_ref
osync_plugin_externalplugin_set_external_command
osync_plugin_externalplugin_unref


Please move osync_member_get_external_command() to opensync_member_internals.h 
and adapt opensync.sym commit your modifications.

Thanks for your contribution!

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] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

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

On Friday 30 October 2009 21:49:22 Daniel Gollub wrote:
> Currently, there is need of stub plugin, which registers the plugin to the
> OpenSync environment. As Graham already suggested in a seperated thread,
> we'll very likely change it - so there is only need to write a simple
> configuration file to register external plugins.

I have a first cut of the external plugin config file ready to check in 
(http://opensync.pastebin.com/m38d98a95).  But I have a couple of questions:

1) When I run the unittests, 17 of them fail.  I don't *think* any of them are 
related to these changes but is that expected at the moment?

The following tests FAILED:
         36 - filter_sync_deny_all (Failed)
        176 - lock_dual_sync_engine_lock (Failed)
        206 - mapping_engine_same_similar_conflict (Failed)
        207 - mapping_engine_same_similar_conflict2 (Failed)
        208 - mapping_engine_same_similar_conflict_multi (Failed)
        227 - multisync_dual_new (Failed)
        228 - multisync_triple_new (Failed)
        239 - multisync_conflict_data_duplicate (Failed)
        240 - multisync_conflict_data_duplicate2 (Failed)
        246 - sync_easy_conflict (Failed)
        247 - sync_easy_new_mapping (Failed)
        248 - sync_easy_conflict_duplicate (Failed)
        249 - sync_easy_conflict_abort (Failed)
        250 - sync_conflict_duplicate2 (Failed)
        251 - sync_conflict_delay (Failed)
        256 - sync_large (Failed)
        261 - sync_initial_slow_sync (Failed)

If it is not expected I will have to do some more checking.

2) I have created an example external plugin config file in 
docs/examples/plugins/src.  Can the existing CMake macros be used to get that 
file installed into the plugin directory (which is where I am looking for 
it -- I look for .xml files first, then .so files)?  I haven't tried it but I 
assume the macros like OPENSYNC_PLUGIN_INSTALL expect a .so file.

I really don't know CMake -- can anyone advise how to get my .xml file 
installed into the plugin directory?

The new code seems to work but there are a few things that still need to be 
done:

3) The XML format includes <ExternalCommand> but I currently ignore it.  My 
plan is that this should be saved in the plugin structure and could be used 
as a default for the config option that Henrik is adding.

4) If the .xml and the .so are both present, they both get loaded and two 
plugins exist with the same name.  I thought of adding error checking to  
osync_plugin_set_name to fail if a plugin of the same name is already loaded.  
But I have just noticed that none of the osync_plugin_set_... calls have 
OSyncError parameters.  Should they?  This would be an API change (to a 
widely used API).

5) There is no unittest for this code yet.

I'm not sure if I will get time to work on this further on Sunday -- I will 
check it in by the end of Sunday.

Graham

[Opensync-devel] [RFC][PATCH] External command in plugin configuration file

[Henrik /K. <he...@ka...>]

Dear all,

Following Daniel's checkin of the client and example code for external 
plugin, here is a patch (on -r5895) which allows a member to set an 
ExternalCommand in the plugin configuration file. This command will be 
executed by the proxy to start up the external process.

Your comments would be most appreciated.

/Henrik

Re: [Opensync-devel] [trunk] OSYNC_START_TYPE_EXTERNAL example / OSyncClient API changes

[Henrik /K. <he...@ka...>]

Great!

Thanks a lot Daniel.
Works like a charm!

/Henrik


Daniel Gollub wrote:
> Hi,
>
>
> finally we have an example implementation for OSYNC_START_TYPE_EXTERNAL.
>
> [...]