From groupdav@opengroupware.org Tue Mar 13 10:48:15 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Tue, 13 Mar 2007 21:48:15 +1100 Subject: [GroupDAV] Funambol connector 1801 Message-ID: Hello all, I've fixed a bunch of problems with the connector (particularly events), OpenGroupware, and some general service fixes. Nokia devices should now sync if they previously reported syncs as "discarded". Its available from http://comalies.citadel.org/~matt/funambol/latest/ . The installation pattern in the same, however, the docs haven't been rewritten yet. Planned for next release: - Properly handle recurrence events being added to an OGo/similar server. - New logging mechanism for use in production environments Changed: - Changed PUT URL to "new.ics" to ensure added events are public in Ogo. - Organizer info will be added to new sync items if the user is set up right in the Funambol user database - There is now a presumption that devices will lose data, as such events updated on the device will be merged into the ones on the server so attendees and other details stick. - Priority defined as 5 by default if not present - Sequence:0 and Transp:Opaque, Class:Public - Updated/New events from the device are reloaded then sent back to the device (fixes creating, then updating an event on device from Ogo) - Set the type in the SyncML item metadata because Nokia E61 checks it. (this previously didn't occur because previous funambol releases and various devices didn't do so) From groupdav@opengroupware.org Tue Mar 13 20:45:59 2007 From: groupdav@opengroupware.org (Helge Hess) Date: Tue, 13 Mar 2007 21:45:59 +0100 Subject: [GroupDAV] OGo data output issues In-Reply-To: References: Message-ID: On Feb 27, 2007, at 12:13, Mathew McBride wrote: > These may or not be OGo's fault > (could be parsers) - guess here is the best place to raise them > > These are all with ZideStore 1.3 Its not that useful to test against ZideStore 1.3 (OGo 1.0alpha), ZideStore 1.5 (OGo 1.1) has a LOT of improvements in its GroupDAV support. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Wed Mar 14 16:51:37 2007 From: groupdav@opengroupware.org (Tews, Shad) Date: Wed, 14 Mar 2007 10:51:37 -0600 Subject: [GroupDAV] Having problems with basic functionality - Question of setup Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C76659.07F6E9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, here at USA.net we have been testing with the following setup. =20 SUN Solaris version 8 JBOSS version 4.04.GA DS server version 5.0.10 JDK version 1.5.0-09 GroupDAV version 1801 Funambol database is an Oracle DB version 10.2 I am testing with the Outlook plugin version 3.0.15 on a PC and the = Funambol Smart Phone plugin version 3.1.3 running Windows Mobile OS = version 5 on a Motorola Q device. =20 I just installed the new 1801 and because some of the basic = functionality is not working properly I am concerned about our setup. = With the previous 1792 version of the GroupDAV connector we had managed = to establish iCal event stability with some minor changes but I noticed = that there always seems to be problems with the exceptions in the = funambol engine. Before I start publishing some of the fixes we made I = want to take a step back and make sure our setup is right. I would like = start by finding out how stable all the normal functionality is for = people out there and find out what people are using for their setup. I = am also curious to the extent of testing people are doing. I included a = spreadsheet of a basic set of tests I have been performing and would = like to know if these tests are passing or failing for others. The key = to getting everything working properly seems to be the location and = versions of the right jar files and the correct entries in the = install.properties file. If some could take a minute and look at my = setup and see if they notice any obvious problems I would appreciate it. =20 Here is an ls of our /usr/local/jboss-4.0.4.GA/server/funambol/lib = directory. The JGroupDAV.jar is going to be of differant size than the = one with 1801 release due to some minor changes so please take note.=20 =20 total 31186 drwxr-xr-x 2 root other 2048 Mar 13 22:40 . drwxr-xr-x 9 root other 512 Mar 13 22:39 .. -rw-r--r-- 1 root other 55043 Mar 13 22:40 JGroupDAV.jar -rw-r--r-- 1 root other 54850 Mar 13 22:39 activation.jar -rw-r--r-- 1 root other 443587 Mar 13 22:39 antlr-2.7.6.jar -rw-r--r-- 1 root other 5181 Mar 13 22:39 = autonumber-plugin.jar -rw-r--r-- 1 root other 516253 Mar 13 22:39 bcel.jar -rw-r--r-- 1 root other 22245 Mar 13 22:39 = bindingservice-plugin.jar -rw-r--r-- 1 root other 175967 Mar 13 22:39 bsf.jar -rw-r--r-- 1 root other 242480 Mar 13 22:39 bsh-1.3.0.jar -rw-r--r-- 1 root other 12835 Mar 13 22:39 bsh-deployer.jar -rw-r--r-- 1 root other 328579 Mar 13 22:39 cglib.jar -rw-r--r-- 1 root other 46725 Mar 13 22:40 = commons-codec-1.3.jar -rw-r--r-- 1 root other 165304 Mar 13 22:39 = commons-collections.jar -rw-r--r-- 1 root other 225626 Mar 13 22:39 = commons-httpclient.jar -rw-r--r-- 1 root other 63980 Mar 13 22:40 = commons-lang-1.0.1.jar -rw-r--r-- 1 root other 52915 Mar 13 22:40 = commons-logging-1.1.jar -rw-r--r-- 1 root other 20937 Mar 13 22:40 = commons-logging-adapters-1.1.jar -rw-r--r-- 1 root other 44598 Mar 13 22:40 = commons-logging-api-1.1.jar -rw-r--r-- 1 root other 31605 Mar 13 22:39 = commons-logging.jar -rw-r--r-- 1 root other 265111 Mar 13 22:40 = foundation-3.0.9.jar -rw-r--r-- 1 root other 6272 Mar 13 22:40 = funambol-admin-dev.jar -rw-r--r-- 1 root other 173257 Mar 13 22:40 = funambol-ext-3.0.4.jar -rw-r--r-- 1 root other 417303 Mar 13 22:40 = funambol-framework.jar -rw-r--r-- 1 root other 2112010 Mar 13 22:39 hibernate3.jar -rw-r--r-- 1 root other 8608 Mar 13 22:39 hsqldb-plugin.jar -rw-r--r-- 1 root other 635958 Mar 13 22:39 hsqldb.jar -rw-r--r-- 1 root other 473546 Mar 13 22:40 = ical4j-1.0-beta1.jar -rw-r--r-- 1 root other 451134 Mar 13 22:39 javassist.jar -rw-r--r-- 1 root other 98722 Mar 13 22:39 javax.servlet.jar -rw-r--r-- 1 root other 51519 Mar 13 22:39 = javax.servlet.jsp.jar -rw-r--r-- 1 root other 331606 Mar 13 22:39 = jboss-backport-concurrent.jar -rw-r--r-- 1 root other 80861 Mar 13 22:39 = jboss-common-jdbc-wrapper.jar -rw-r--r-- 1 root other 14760 Mar 13 22:39 = jboss-hibernate.jar -rw-r--r-- 1 root other 442880 Mar 13 22:39 jboss-j2ee.jar -rw-r--r-- 1 root other 30395 Mar 13 22:39 jboss-jaxrpc.jar -rw-r--r-- 1 root other 187041 Mar 13 22:39 jboss-jca.jar -rw-r--r-- 1 root other 14216 Mar 13 22:39 jboss-jsr77.jar -rw-r--r-- 1 root other 63912 Mar 13 22:39 jboss-jsr88.jar -rw-r--r-- 1 root other 160853 Mar 13 22:39 = jboss-management.jar -rw-r--r-- 1 root other 57990 Mar 13 22:39 = jboss-monitoring.jar -rw-r--r-- 1 root other 8362 Mar 13 22:39 = jboss-remoting-int.jar -rw-r--r-- 1 root other 608309 Mar 13 22:39 jboss-remoting.jar -rw-r--r-- 1 root other 22113 Mar 13 22:39 jboss-saaj.jar -rw-r--r-- 1 root other 124943 Mar 13 22:39 = jboss-serialization.jar -rw-r--r-- 1 root other 49226 Mar 13 22:39 jboss-srp.jar -rw-r--r-- 1 root other 53755 Mar 13 22:39 = jboss-transaction.jar -rw-r--r-- 1 root other 2101020 Mar 13 22:39 jboss.jar -rw-r--r-- 1 root other 510551 Mar 13 22:39 jbossmq.jar -rw-r--r-- 1 root other 48168 Mar 13 22:39 jbossretro-rt.jar -rw-r--r-- 1 root other 302998 Mar 13 22:39 jbosssx.jar -rw-r--r-- 1 root other 1330710 Mar 13 22:39 jgroups-all.jar -rw-r--r-- 1 root other 30544 Mar 13 22:39 = jmx-adaptor-plugin.jar -rw-r--r-- 1 root other 38713 Mar 13 22:39 jnpserver.jar -rw-r--r-- 1 root other 502389 Mar 13 22:40 joda-time-1.0.jar -rw-r--r-- 1 root other 3520 Mar 13 22:39 jpl-pattern.jar -rw-r--r-- 1 root other 16992 Mar 13 22:39 jpl-util.jar -rw-r--r-- 1 root other 353235 Mar 13 22:39 log4j.jar -rw-r--r-- 1 root other 5736 Mar 13 22:39 mail-plugin.jar -rw-r--r-- 1 root other 327831 Mar 13 22:39 mail.jar -rw-r--r-- 1 root other 8799 Mar 13 22:39 = properties-plugin.jar -rw-r--r-- 1 root other 3805 Mar 13 22:39 = scheduler-plugin-example.jar -rw-r--r-- 1 root other 47817 Mar 13 22:39 = scheduler-plugin.jar -rw-r--r-- 1 root other 199556 Mar 13 22:40 smallsql.jar -rw-r--r-- 1 root other 98256 Mar 13 22:39 snmp-support.jar -rw-r--r-- 1 root other 164985 Mar 13 22:39 wsdl4j.jar -rw-r--r-- 1 root other 2651 Mar 13 22:39 xmlentitymgr.jar =20 My install.properties file looks like this -------------------------------------- server-uri=3D context-path=3D/funambol # dbms=3Doracle # ORACLE # =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # jdbc.classpath=3D/Funambol/tools/ojdbc14/ojdbc14.jar jdbc.driver=3Doracle.jdbc.driver.OracleDriver jdbc.url=3Djdbc:oracle:thin:@165.212.101.9:1521:dvug jdbc.user=3Dfunambol jdbc.password=3Dfunambol # # ## Originals ## --------- ##jdbc.classpath=3D/opt/postgresql/share/java/postgresql.jar ##jdbc.driver=3Dorg.postgresql.Driver ##jdbc.url=3Djdbc:postgresql://localhost/funambol ##jdbc.user=3Dfunambol ##jdbc.password=3D ## --------- # # Modules definitions # modules-to-install=3Dpdi-3.0.5,groupdav-1.1.1802 modules-to-uninstall=3D I am curious if someone would be willing to provide me a tarball of = their setup or a full listing of all the files in their app server = directory and their funambol home directory.=20 =20 =20 Also, I am going through right now to see if the changes we made to the 1792 = version are still needed in the 1801 release and if so I will publish = them shortly. One fix I feel is still needed is in the startSync method = for both calendar and vcard objects. If you are trying to delete = multiple items the loop incorrectly increments the value of "i". I = changed the loop as noted below the "USA.net" comment section. I made = this fix in both the ICalendarObjectStore.java and the = vCardObjectStore.java. public void startSync() throws Exception { log.info("Sync started...."); obtrack.init(); List objects =3D = client.listObjects(props.getProperty("groupdav.store")); Map etags =3D client.getEtags(); for (int i =3D 0; i < objects.size(); i++) { String url =3D (String)objects.get(i); // Do we have the object? boolean haveurl =3D obtrack.doesURLExist(url); if (haveurl) { String stuid =3D obtrack.findObjectByURL(url); String stetag =3D obtrack.getObjectEtag(stuid); String getag =3D (String)etags.get(url); if (!stetag.equals(getag)) { updateObjectFromServer(stuid); } else { untouched.add(stuid); } log.fine("We have the URL: " + url); } else { try { addFromServerToStore(url); } catch (Exception ex) { log.throwing(this.getClass().getName(),"startSync",ex); ex.printStackTrace(); } log.fine("We added the URL: " + url); } } // Now find deleted items /* * USA.NET * Changed the looping code to properly handle multiple deletes. */ ArrayList URLarray =3D obtrack.getURLList();=20 for (int i =3D 0; i < URLarray.size(); i++) { String url =3D (String)URLarray.get(i); if (null =3D=3D etags.get(url)) { log.fine("Deleted on server: " + url); deleteFromStore(obtrack.findObjectByURL(url)); } } /* * USA.NET * Old delete loop for (int i =3D 0; i < obtrack.getURLList().size(); i++) { String url =3D (String)obtrack.getURLList().get(i); if (etags.get(url) =3D=3D null) { log.fine("Deleted on server: " + url); deleteFromStore(obtrack.findObjectByURL(url)); } } */ } =20 =20 thanks, Shad Tews USA.net ------_=_NextPart_001_01C76659.07F6E9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
Hi, here at USA.net we = have been testing with the following setup.
=0A=
 
=0A=
SUN Solaris version 8
=0A=
JBOSS version 4.04.GA
=0A=
DS server version 5.0.10
=0A=
JDK version 1.5.0-09
=0A=
GroupDAV version 1801
=0A=
Funambol database is an Oracle DB = version 10.2
=0A=
I am testing with the Outlook plugin = version 3.0.15 on a PC and the Funambol Smart Phone plugin version 3.1.3 = running Windows Mobile OS version 5 on a Motorola Q device.
=0A=
 
=0A=
I just installed the new 1801 and = because some of the basic functionality is not working properly I am = concerned about our setup. With the previous 1792 version of the = GroupDAV connector we had managed to establish iCal event stability with = some minor changes but I noticed that there always seems to be problems = with the exceptions in the funambol engine. Before I start publishing = some of the fixes we made I want to take a step back and make sure = our setup is right. I would like start by finding out how stable = all the normal functionality is for people out there and find out = what people are using for their setup. I am also curious to the extent = of testing people are doing. I included a spreadsheet of a basic set of = tests I have been performing and would like to know if these tests are = passing or failing for others. The key to getting everything working = properly seems to be the location and versions of the right jar files = and the correct entries in the install.properties file. If some could = take a minute and look at my setup and see if they notice any obvious = problems I would appreciate it.
=0A=
 
=0A=
Here is an ls of our = /usr/local/jboss-4.0.4.GA/server/funambol/lib directory. The = JGroupDAV.jar is going to be of differant size than the one with 1801 = release due to some minor changes so please take note. 
=0A=
 
=0A=
total 31186
drwxr-xr-x   2 = root     other       = 2048 Mar 13 22:40 .
drwxr-xr-x   9 = root     = other        512 Mar 13 22:39 = .
-rw-r--r--   1 root     = other      55043 Mar 13 22:40 = JGroupDAV.jar
-rw-r--r--   1 root     = other      54850 Mar 13 22:39 = activation.jar
-rw-r--r--   1 root     = other     443587 Mar 13 22:39 = antlr-2.7.6.jar
-rw-r--r--   1 root     = other       5181 Mar 13 22:39 = autonumber-plugin.jar
-rw-r--r--   1 = root     other     516253 Mar 13 = 22:39 bcel.jar
-rw-r--r--   1 root     = other      22245 Mar 13 22:39 = bindingservice-plugin.jar
-rw-r--r--   1 = root     other     175967 Mar 13 = 22:39 bsf.jar
-rw-r--r--   1 root     = other     242480 Mar 13 22:39 = bsh-1.3.0.jar
-rw-r--r--   1 root     = other      12835 Mar 13 22:39 = bsh-deployer.jar
-rw-r--r--   1 = root     other     328579 Mar 13 = 22:39 cglib.jar
-rw-r--r--   1 root     = other      46725 Mar 13 22:40 = commons-codec-1.3.jar
-rw-r--r--   1 = root     other     165304 Mar 13 = 22:39 commons-collections.jar
-rw-r--r--   1 = root     other     225626 Mar 13 = 22:39 commons-httpclient.jar
-rw-r--r--   1 = root     other      63980 = Mar 13 22:40 commons-lang-1.0.1.jar
-rw-r--r--   1 = root     other      52915 = Mar 13 22:40 commons-logging-1.1.jar
-rw-r--r--   1 = root     other      20937 = Mar 13 22:40 commons-logging-adapters-1.1.jar
-rw-r--r--   = 1 root     other      44598 = Mar 13 22:40 commons-logging-api-1.1.jar
-rw-r--r--   1 = root     other      31605 = Mar 13 22:39 commons-logging.jar
-rw-r--r--   1 = root     other     265111 Mar 13 = 22:40 foundation-3.0.9.jar
-rw-r--r--   1 = root     other       = 6272 Mar 13 22:40 funambol-admin-dev.jar
-rw-r--r--   1 = root     other     173257 Mar 13 = 22:40 funambol-ext-3.0.4.jar
-rw-r--r--   1 = root     other     417303 Mar 13 = 22:40 funambol-framework.jar
-rw-r--r--   1 = root     other    2112010 Mar 13 = 22:39 hibernate3.jar
-rw-r--r--   1 = root     other       = 8608 Mar 13 22:39 hsqldb-plugin.jar
-rw-r--r--   1 = root     other     635958 Mar 13 = 22:39 hsqldb.jar
-rw-r--r--   1 = root     other     473546 Mar 13 = 22:40 ical4j-1.0-beta1.jar
-rw-r--r--   1 = root     other     451134 Mar 13 = 22:39 javassist.jar
-rw-r--r--   1 = root     other      98722 = Mar 13 22:39 javax.servlet.jar
-rw-r--r--   1 = root     other      51519 = Mar 13 22:39 javax.servlet.jsp.jar
-rw-r--r--   1 = root     other     331606 Mar 13 = 22:39 jboss-backport-concurrent.jar
-rw-r--r--   1 = root     other      80861 = Mar 13 22:39 jboss-common-jdbc-wrapper.jar
-rw-r--r--   1 = root     other      14760 = Mar 13 22:39 jboss-hibernate.jar
-rw-r--r--   1 = root     other     442880 Mar 13 = 22:39 jboss-j2ee.jar
-rw-r--r--   1 = root     other      30395 = Mar 13 22:39 jboss-jaxrpc.jar
-rw-r--r--   1 = root     other     187041 Mar 13 = 22:39 jboss-jca.jar
-rw-r--r--   1 = root     other      14216 = Mar 13 22:39 jboss-jsr77.jar
-rw-r--r--   1 = root     other      63912 = Mar 13 22:39 jboss-jsr88.jar
-rw-r--r--   1 = root     other     160853 Mar 13 = 22:39 jboss-management.jar
-rw-r--r--   1 = root     other      57990 = Mar 13 22:39 jboss-monitoring.jar
-rw-r--r--   1 = root     other       = 8362 Mar 13 22:39 jboss-remoting-int.jar
-rw-r--r--   1 = root     other     608309 Mar 13 = 22:39 jboss-remoting.jar
-rw-r--r--   1 = root     other      22113 = Mar 13 22:39 jboss-saaj.jar
-rw-r--r--   1 = root     other     124943 Mar 13 = 22:39 jboss-serialization.jar
-rw-r--r--   1 = root     other      49226 = Mar 13 22:39 jboss-srp.jar
-rw-r--r--   1 = root     other      53755 = Mar 13 22:39 jboss-transaction.jar
-rw-r--r--   1 = root     other    2101020 Mar 13 = 22:39 jboss.jar
-rw-r--r--   1 root     = other     510551 Mar 13 22:39 = jbossmq.jar
-rw-r--r--   1 root     = other      48168 Mar 13 22:39 = jbossretro-rt.jar
-rw-r--r--   1 = root     other     302998 Mar 13 = 22:39 jbosssx.jar
-rw-r--r--   1 = root     other    1330710 Mar 13 = 22:39 jgroups-all.jar
-rw-r--r--   1 = root     other      30544 = Mar 13 22:39 jmx-adaptor-plugin.jar
-rw-r--r--   1 = root     other      38713 = Mar 13 22:39 jnpserver.jar
-rw-r--r--   1 = root     other     502389 Mar 13 = 22:40 joda-time-1.0.jar
-rw-r--r--   1 = root     other       = 3520 Mar 13 22:39 jpl-pattern.jar
-rw-r--r--   1 = root     other      16992 = Mar 13 22:39 jpl-util.jar
-rw-r--r--   1 = root     other     353235 Mar 13 = 22:39 log4j.jar
-rw-r--r--   1 root     = other       5736 Mar 13 22:39 = mail-plugin.jar
-rw-r--r--   1 root     = other     327831 Mar 13 22:39 = mail.jar
-rw-r--r--   1 root     = other       8799 Mar 13 22:39 = properties-plugin.jar
-rw-r--r--   1 = root     other       = 3805 Mar 13 22:39 scheduler-plugin-example.jar
-rw-r--r--   = 1 root     other      47817 = Mar 13 22:39 scheduler-plugin.jar
-rw-r--r--   1 = root     other     199556 Mar 13 = 22:40 smallsql.jar
-rw-r--r--   1 = root     other      98256 = Mar 13 22:39 snmp-support.jar
-rw-r--r--   1 = root     other     164985 Mar 13 = 22:39 wsdl4j.jar
-rw-r--r--   1 = root     other       = 2651 Mar 13 22:39 xmlentitymgr.jar
=0A=

 

=0A=

My install.properties file looks like = this
--------------------------------------

=0A=

server-uri=3D
context-path=3D/funambol

=0A=

#
dbms=3Doracle

=0A=

# ORACLE
# = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#
jdbc.classpath=3D/Funambol/tools/o= jdbc14/ojdbc14.jar
jdbc.driver=3Doracle.jdbc.driver.OracleDriver
jd= bc.url=3Djdbc:oracle:thin:@165.212.101.9:1521:dvug
jdbc.user=3Dfunambo= l
jdbc.password=3Dfunambol
#
#
## Originals
## = ---------
##jdbc.classpath=3D/opt/postgresql/share/java/postgresql.jar=
##jdbc.driver=3Dorg.postgresql.Driver
##jdbc.url=3Djdbc:postgresql= ://localhost/funambol
##jdbc.user=3Dfunambol
##jdbc.password=3D
= ## ---------

=0A=

#
# Modules = definitions
#
modules-to-install=3Dpdi-3.0.5,groupdav-1.1.1802
m= odules-to-uninstall=3D

=0A=
I am curious if someone would be willing to provide me a tarball of = their setup or a full listing of all the files in their app server = directory and their funambol home directory.
=0A=
 
=0A=
 
=0A=
Also,
=0A=
I am going through right now to see if the changes we made to the = 1792 version are still needed in the 1801 release and if so I will = publish them shortly. One fix I feel is still needed is in the startSync = method for both calendar and vcard objects. If you are trying to delete = multiple items the loop incorrectly increments the value of "i". I = changed the loop as noted below the "USA.net" comment section. I made = this fix in both the ICalendarObjectStore.java and the = vCardObjectStore.java.
=0A=

public void startSync() = throws Exception {

=0A=

log.info("Sync = started....");

=0A=

obtrack.init();

=0A=

List objects =3D client.listObjects(props.getProperty("groupdav.store"));

=0A=

Map etags =3D client.getEtags();

=0A=

for (int i =3D 0; i < objects.size(); = i++) {

=0A=

String url =3D (String)objects.get(i);

=0A=

// Do we have the = object?

=0A=

boolean haveurl =3D obtrack.doesURLExist(url);

=0A=

if (haveurl) {

=0A=

String stuid =3D obtrack.findObjectByURL(url);

=0A=

String stetag =3D obtrack.getObjectEtag(stuid);

=0A=

String getag =3D (String)etags.get(url);

=0A=

if (!stetag.equals(getag)) {

=0A=

updateObjectFromServer(stuid);

=0A=

} else {

=0A=

untouched.add(stuid);

=0A=

}

=0A=

log.fine("We have the URL: = " + url);

=0A=

} else {

=0A=

try {

=0A=

addFromServerToStore(url);

=0A=

} catch (Exception ex) {

=0A=

log.throwing(this.getClass().getName(),"startSync",ex);

=0A=

ex.printStackTrace();

=0A=

}

=0A=

log.fine("We added the URL: = " + url);

=0A=

}

=0A=

=0A=

}

=0A=

// Now find = deleted items

=0A=

/*

=0A=

* USA.NET

=0A=

* Changed the looping code to properly handle multiple = deletes.

=0A=

*/

=0A=

ArrayList URLarray =3D obtrack.getURLList();

=0A=

for (int i =3D 0; i < URLarray.size(); = i++)

=0A=

{

=0A=

String url =3D (String)URLarray.get(i);

=0A=

if (null =3D=3D etags.get(url))

=0A=

{

=0A=

log.fine("Deleted on server: = " + url);

=0A=

deleteFromStore(obtrack.findObjectByURL(url));

=0A=

}

=0A=

}

=0A=

=0A=

/*

=0A=

* USA.NET

=0A=

* Old delete loop

=0A=

for (int i =3D 0; i < obtrack.getURLList().size(); = i++) {

=0A=

String url =3D (String)obtrack.getURLList().get(i);

=0A=

if (etags.get(url) =3D=3D null) {

=0A=

log.fine("Deleted on server: " + url);

=0A=

deleteFromStore(obtrack.findObjectByURL(url));

=0A=

}

=0A=

}

=0A=

*/

=0A=

}

=0A=

 

=0A=

 

=0A=

thanks,

=0A=

Shad = Tews
USA.net



 

 

------_=_NextPart_001_01C76659.07F6E9A0-- From groupdav@opengroupware.org Thu Mar 15 11:43:24 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Thu, 15 Mar 2007 22:43:24 +1100 Subject: [GroupDAV] Having problems with basic functionality - Question of setup In-Reply-To: Message-ID: Thanks for the deleted items fix! Your setup should be right as long as all the jars are in the right place. If the source creation panel in the admin tool states the version you are using is right, and you are able to create a source using it, most of the time, things should work. Usually before sticking a build on the server I do add/modify/delete tests from both sides just to see if any development I've done has killed something. I typically test with the Synthesis PalmOS client - it works just as well in the PalmOS Simulator as it does on actual hardware too. Unfortunately the Outlook plugin is a bad client to test with. It frequently locks up and has even crashed on me several times. NextHaus has a payware client which is much more stable but still unstable in some situations. In JGroupDAV I've started to write some unit tests with JUnit (test/net/bionicmessage/* ). I'd like to write an automated test suite for the connector itself some time in the future, hopefully using Funambol or someone elses SyncML library. On 15/3/07 3:51 AM, "Tews, Shad" wrote: > Hi, here at USA.net we have been testing with the following setup. > > SUN Solaris version 8 > JBOSS version 4.04.GA > DS server version 5.0.10 > JDK version 1.5.0-09 > GroupDAV version 1801 > Funambol database is an Oracle DB version 10.2 > I am testing with the Outlook plugin version 3.0.15 on a PC and the Funambol > Smart Phone plugin version 3.1.3 running Windows Mobile OS version 5 on a > Motorola Q device. > > I just installed the new 1801 and because some of the basic functionality is > not working properly I am concerned about our setup. With the previous 1792 > version of the GroupDAV connector we had managed to establish iCal event > stability with some minor changes but I noticed that there always seems to be > problems with the exceptions in the funambol engine. Before I start publishing > some of the fixes we made I want to take a step back and make sure our setup > is right. I would like start by finding out how stable all the normal > functionality is for people out there and find out what people are using for > their setup. I am also curious to the extent of testing people are doing. I > included a spreadsheet of a basic set of tests I have been performing and > would like to know if these tests are passing or failing for others. The key > to getting everything working properly seems to be the location and versions > of the right jar files and the correct entries in the install.properties file. > If some could take a minute and look at my setup and see if they notice any > obvious problems I would appreciate it. > > Here is an ls of our /usr/local/jboss-4.0.4.GA/server/funambol/lib directory. > The JGroupDAV.jar is going to be of differant size than the one with 1801 > release due to some minor changes so please take note. > > > > > > > > From groupdav@opengroupware.org Fri Mar 16 10:34:33 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Fri, 16 Mar 2007 21:34:33 +1100 Subject: [GroupDAV] Having problems with basic functionality - Question of setup In-Reply-To: Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3256925674_1198289 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hello all, If items aren=B9t appearing on sync, theres a bug which has managed to hide from me and I=B9ll have a fix out soon. --B_3256925674_1198289 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [GroupDAV] Having problems with basic functionality - Question o= f setup Hello= all,

If items aren’t appearing on sync, theres a bug which has managed to = hide from me and I’ll have a fix out soon.   --B_3256925674_1198289-- From groupdav@opengroupware.org Fri Mar 16 13:50:04 2007 From: groupdav@opengroupware.org (Tews, Shad) Date: Fri, 16 Mar 2007 07:50:04 -0600 Subject: [GroupDAV] Having problems with basic functionality - Question of setup References: Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C767D2.9713F408 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is one thing I noticed. When doing an initial sync, it does a = PROPFIND, then the PUT, then a GET. The GET has one too many leading = slashes and when I look at the smallsql cache at the ds-server side it = is empty. Hope that helps. =20 Here is an example =20 17392 [ 1] Mar 15 22:11:42 Start: PROPFIND = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/ 17392 [ 1] Mar 15 22:11:42 Header Accept =3D text/* 17392 [ 1] Mar 15 22:11:42 Header Accept-Language =3D en 17392 [ 1] Mar 15 22:11:42 Header Authorization =3D Basic = c2hhZDJzQGRldm8wNDAyLmRldi51c2EubmV0OmFiYzEyMw=3D=3D 17392 [ 1] Mar 15 22:11:42 Header Cache-control =3D no-cache 17392 [ 1] Mar 15 22:11:42 Header Content-Length =3D 95 17392 [ 1] Mar 15 22:11:42 Header Content-Type =3D = text/xml;charset=3Dutf-8 17392 [ 1] Mar 15 22:11:42 Header Depth =3D 1 17392 [ 1] Mar 15 22:11:42 Header Host =3D dav.dev.usa.net:80 17392 [ 1] Mar 15 22:11:42 Header Pragma =3D no-cache 17392 [ 1] Mar 15 22:11:42 AccountID: 22003007694000 17392 [ 1] Mar 15 22:11:42 Done: PROPFIND = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/ 17639 [ 1] Mar 15 22:11:43 Start: PUT = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/new.ics 17639 [ 1] Mar 15 22:11:43 Header Authorization =3D Basic = c2hhZDJzQGRldm8wNDAyLmRldi51c2EubmV0OmFiYzEyMw=3D=3D 17639 [ 1] Mar 15 22:11:43 Header Content-Length =3D 396 17639 [ 1] Mar 15 22:11:43 Header Content-Type =3D text/calendar; = charset=3Dutf-8 17639 [ 1] Mar 15 22:11:43 Header Host =3D dav.dev.usa.net:80 17639 [ 1] Mar 15 22:11:43 Header If-None-Match =3D * 17639 [ 1] Mar 15 22:11:43 Header User-Agent =3D BionicMessage.net = GroupDAV {0.9;Java} 17639 [ 1] Mar 15 22:11:43 AccountID: 22003007694000 17639 [ 1] Mar 15 22:11:43 Opened temp file /var/tmp/davA3a4CI. = Reading data... 17639 [ 1] Mar 15 22:11:43 Finished reading data. 17639 [ 1] Mar 15 22:11:43 UID found: = 00000000259ADD447E5E8F4287752596EE36834544432000 17639 [ 1] Mar 15 22:11:43 Calling Calendar.DavImportEvent 17639 [ 1] Mar 15 22:11:43 Done Calling Calendar.DavImportEvent 17639 [ 1] Mar 15 22:11:43 Think we succeeded with the Import 17639 [ 1] Mar 15 22:11:43 Done: PUT = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/new.ics 17397 [ 1] Mar 15 22:17:42 Start: GET = //groupdav/shad2s@devo0402.dev.usa.net/Calendar/00000000259AD D447E5E8F4287752596EE36834544432000 17397 [ 1] Mar 15 22:17:42 Header Authorization =3D Basic = c2hhZDJzQGRldm8wNDAyLmRldi51c2EubmV0OmFiYzEyMw=3D=3D 17397 [ 1] Mar 15 22:17:42 Header Content-Length =3D 0 17397 [ 1] Mar 15 22:17:42 Header Host =3D dav.dev.usa.net:80 17397 [ 1] Mar 15 22:17:42 Header User-Agent =3D BionicMessage.net = GroupDAV {0.9;Java} 17397 [ 1] Mar 15 22:17:42 AccountID: 22003007694000 17397 [ 1] Mar 15 22:17:42 Done: GET = //groupdav/shad2s@devo0402.dev.usa.net/Calendar/00000000259ADD 447E5E8F4287752596EE36834544432000 =20 Shad ------_=_NextPart_001_01C767D2.9713F408 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [GroupDAV] Having problems with basic = functionality - Question of setup=0A= =0A= =0A= =0A=
Here = is one thing I noticed. When doing an initial sync, it does a PROPFIND, = then the PUT, then a GET. The GET has one too many leading slashes and = when I look at the smallsql cache at the ds-server side it is empty. = Hope that helps.
=0A=
 
=0A=
Here is an = example
=0A=
 
=0A=
17392 [    1] = Mar 15 22:11:42 Start: PROPFIND = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/
17392 = [    1] Mar 15 22:11:42 Header Accept =3D text/*
17392 = [    1] Mar 15 22:11:42 Header Accept-Language =3D = en
17392 [    1] Mar 15 22:11:42 Header Authorization = =3D Basic c2hhZDJzQGRldm8wNDAyLmRldi51c2EubmV0OmFiYzEyMw=3D=3D
17392 = [    1] Mar 15 22:11:42 Header Cache-control =3D = no-cache
17392 [    1] Mar 15 22:11:42 Header = Content-Length =3D 95
17392 [    1] Mar 15 22:11:42 = Header Content-Type =3D text/xml;charset=3Dutf-8
17392 = [    1] Mar 15 22:11:42 Header Depth =3D 1
17392 = [    1] Mar 15 22:11:42 Header Host =3D = dav.dev.usa.net:80
17392 [    1] Mar 15 22:11:42 = Header Pragma =3D no-cache
17392 [    1] Mar 15 = 22:11:42 AccountID: 22003007694000
17392 [    1] Mar = 15 22:11:42 Done: PROPFIND = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/
17639 = [    1] Mar 15 22:11:43 Start: = PUT      = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/new.ics
17639 = [    1] Mar 15 22:11:43 Header Authorization =3D Basic = c2hhZDJzQGRldm8wNDAyLmRldi51c2EubmV0OmFiYzEyMw=3D=3D
17639 = [    1] Mar 15 22:11:43 Header Content-Length =3D = 396
17639 [    1] Mar 15 22:11:43 Header Content-Type = =3D text/calendar; charset=3Dutf-8
17639 [    1] Mar = 15 22:11:43 Header Host =3D dav.dev.usa.net:80
17639 = [    1] Mar 15 22:11:43 Header If-None-Match =3D = *
17639 [    1] Mar 15 22:11:43 Header User-Agent =3D = BionicMessage.net GroupDAV {0.9;Java}
17639 [    1] = Mar 15 22:11:43 AccountID: 22003007694000
17639 [    = 1] Mar 15 22:11:43 Opened temp file /var/tmp/davA3a4CI.  Reading = data...
17639 [    1] Mar 15 22:11:43 Finished reading = data.
17639 [    1] Mar 15 22:11:43 UID found: = 00000000259ADD447E5E8F4287752596EE36834544432000
17639 = [    1] Mar 15 22:11:43 Calling = Calendar.DavImportEvent
17639 [    1] Mar 15 22:11:43 = Done Calling Calendar.DavImportEvent
17639 [    1] Mar = 15 22:11:43 Think we succeeded with the Import
17639 = [    1] Mar 15 22:11:43 Done: = PUT      = /groupdav/shad2s@devo0402.dev.usa.net/Calendar/new.ics
17397 = [    1] Mar 15 22:17:42 Start: = GET      = //groupdav/shad2s@devo0402.dev.usa.net/Calendar/00000000259AD
D= 447E5E8F4287752596EE36834544432000
17397 [    1] Mar = 15 22:17:42 Header Authorization =3D Basic = c2hhZDJzQGRldm8wNDAyLmRldi51c2EubmV0OmFiYzEyMw=3D=3D
17397 = [    1] Mar 15 22:17:42 Header Content-Length =3D = 0
17397 [    1] Mar 15 22:17:42 Header Host =3D = dav.dev.usa.net:80
17397 [    1] Mar 15 22:17:42 = Header User-Agent =3D BionicMessage.net GroupDAV {0.9;Java}
17397 = [    1] Mar 15 22:17:42 AccountID: = 22003007694000
17397 [    1] Mar 15 22:17:42 Done: = GET      = //groupdav/shad2s@devo0402.dev.usa.net/Calendar/00000000259ADD
= 447E5E8F4287752596EE36834544432000
=0A=
 
=0A=
Shad


 

 

------_=_NextPart_001_01C767D2.9713F408-- From groupdav@opengroupware.org Mon Mar 19 10:30:31 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Mon, 19 Mar 2007 21:30:31 +1100 Subject: [GroupDAV] Connector 1810 Message-ID: This should be usable again, sorry for the mix up on my part. Also fixed is the handling of some all day events in the ical2->funambol data converter. People using tomcat should remove the jar from the previous release first, i.e rm tomcat/webapps/funambol/WEB-INF/groupdav-1.1.1801.jar Download from http://comalies.citadel.org/~matt/funambol/latest/ And http://latest.bionicmessage.net/ From groupdav@opengroupware.org Mon Mar 19 22:52:05 2007 From: groupdav@opengroupware.org (Tews, Shad) Date: Mon, 19 Mar 2007 16:52:05 -0600 Subject: [GroupDAV] Not sync'ing updates from Outlook to Server References: Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C76A79.37479694 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C76A79.37479694" ------_=_NextPart_002_01C76A79.37479694 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is what I am testing and what I am seeing. =20 1) I create an event in Outlook. 2) I sync the event to our server where it does appear in the Calendar. = I see all the commands go through and they look ok. 3) I add a location to the event in Outlook. 4) I try and sync again but the location does not appear on the server. =20 I cut and pasted the following into this log file. =20 First part ------------ Our log file showing the PROPFIND, PUT, and GET commands. =20 Second Part ---------------- The storelog.html file for the PROPFIND, PUT, and GET =20 Third Part ------------- Our log file showing just a PROPFIND coming through after I updated the = location and tried to sync =20 Fourth Part --------------- The storelog.html file with the sync after I updated the location. =20 It seems like it does not recognize the fact that there was an update = made at the client side. If I delete the event and sync it does delete = the event on the server. Let me know if you need any other logs. =20 thanks, Shad ------_=_NextPart_002_01C76A79.37479694 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [GroupDAV] Connector 1810=0A= =0A= =0A= =0A=
=0A=
Here is what I am testing and what I am = seeing.
=0A=
 
=0A=
1) I create an event in = Outlook.
=0A=
2) I sync the event to our server where it = does appear in the Calendar. I see all the commands go through and they = look ok.
=0A=
3) I add a location to the event in = Outlook.
=0A=
4) I try and sync again but the location = does not appear on the server.
=0A=
 
=0A=
I cut and pasted the following into = this log file.
=0A=
 
=0A=
First part
=0A=
------------
=0A=
Our log file showing the PROPFIND, PUT, = and GET commands.
=0A=
 
=0A=
Second Part
=0A=
----------------
=0A=
The storelog.html file for the PROPFIND, = PUT, and GET
=0A=
 
=0A=
Third Part
=0A=
-------------
=0A=
Our log file showing just a PROPFIND = coming through after I updated the location and tried to = sync
=0A=
 
=0A=
Fourth Part
=0A=
---------------
=0A=
The storelog.html file with the sync after = I updated the location.
=0A=
 
=0A=
It seems like it does not recognize the = fact that there was an update made at the client side. If I delete the = event and sync it does delete the event on the server. Let me know if = you need any other logs.
=0A=
 
=0A=
thanks,
=0A=
Shad


 

 

= ------_=_NextPart_002_01C76A79.37479694-- ------_=_NextPart_001_01C76A79.37479694 Content-Type: text/plain; name="log-files.txt" Content-Transfer-Encoding: base64 Content-Description: log-files.txt Content-Disposition: attachment; filename="log-files.txt" MTczOTggWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzEgU3RhcnQ6IFBST1BGSU5EIC9ncm91cGRhdi9z aGFkMnNAZGV2bzA0MDIuZGV2LnVzYS5uZXQvQ2FsZW5kYXIvDQoxNzM5OCBbICAgIDFdIE1hciAx OSAyMjozNzozMSBSZXF1ZXN0IEhlYWRlcjogQWNjZXB0ID0gdGV4dC8qDQoxNzM5OCBbICAgIDFd IE1hciAxOSAyMjozNzozMSBSZXF1ZXN0IEhlYWRlcjogQWNjZXB0LUxhbmd1YWdlID0gZW4NCjE3 Mzk4IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMxIFJlcXVlc3QgSGVhZGVyOiBBdXRob3JpemF0aW9u ID0gQmFzaWMgYzJoaFpESnpRR1JsZG04d05EQXlMbVJsZGk1MWMyRXVibVYwT21GaVl6RXlNdz09 DQoxNzM5OCBbICAgIDFdIE1hciAxOSAyMjozNzozMSBSZXF1ZXN0IEhlYWRlcjogQ2FjaGUtY29u dHJvbCA9IG5vLWNhY2hlDQoxNzM5OCBbICAgIDFdIE1hciAxOSAyMjozNzozMSBSZXF1ZXN0IEhl YWRlcjogQ29udGVudC1MZW5ndGggPSA5NQ0KMTczOTggWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzEg UmVxdWVzdCBIZWFkZXI6IENvbnRlbnQtVHlwZSA9IHRleHQveG1sO2NoYXJzZXQ9dXRmLTgNCjE3 Mzk4IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMxIFJlcXVlc3QgSGVhZGVyOiBEZXB0aCA9IDENCjE3 Mzk4IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMxIFJlcXVlc3QgSGVhZGVyOiBIb3N0ID0gZGF2LmRl di51c2EubmV0OjgwDQoxNzM5OCBbICAgIDFdIE1hciAxOSAyMjozNzozMSBSZXF1ZXN0IEhlYWRl cjogUHJhZ21hID0gbm8tY2FjaGUNCjE3Mzk4IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMxIEFjY291 bnRJRDogMjIwMDMwMDc2OTQwMDANCjE3Mzk4IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMxIFJlc3Bv bnNlIEhlYWRlcjogWC1Qb3dlcmVkLUJ5ID0gUEhQLzUuMi4wDQoxNzM5OCBbICAgIDFdIE1hciAx OSAyMjozNzozMSBSZXNwb25zZSBIZWFkZXI6IFgtRGF2LVBvd2VyZWQtQnktY2IgPSBQSFAgY2xh c3M6IEhUVFBfV2ViREFWX1NlcnZlcl9HUk9VUERBVkRCDQoxNzM5OCBbICAgIDFdIE1hciAxOSAy MjozNzozMSBSZXNwb25zZSBIZWFkZXI6IFgtV2ViREFWLVN0YXR1cyA9IDIwNyBNdWx0aS1TdGF0 dXMNCjE3Mzk4IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMxIFJlc3BvbnNlIEhlYWRlcjogQ29udGVu dC1sZW5ndGggPSA4Nw0KMTczOTggWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzEgUmVzcG9uc2UgSGVh ZGVyOiBDb25uZWN0aW9uID0gY2xvc2UNCjE3Mzk4IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMxIFJl c3BvbnNlIEhlYWRlcjogQ29udGVudC1UeXBlID0gdGV4dC94bWw7IGNoYXJzZXQ9InV0Zi04Ig0K MTczOTggWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzEgRG9uZTogUFJPUEZJTkQgL2dyb3VwZGF2L3No YWQyc0BkZXZvMDQwMi5kZXYudXNhLm5ldC9DYWxlbmRhci8NCjE3Mzk2IFsgICAgMV0gTWFyIDE5 IDIyOjM3OjMyIFN0YXJ0OiBQVVQgICAgICAvZ3JvdXBkYXYvc2hhZDJzQGRldm8wNDAyLmRldi51 c2EubmV0L0NhbGVuZGFyL25ldy5pY3MNCjE3Mzk2IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMyIFJl cXVlc3QgSGVhZGVyOiBBdXRob3JpemF0aW9uID0gQmFzaWMgYzJoaFpESnpRR1JsZG04d05EQXlM bVJsZGk1MWMyRXVibVYwT21GaVl6RXlNdz09DQoxNzM5NiBbICAgIDFdIE1hciAxOSAyMjozNzoz MiBSZXF1ZXN0IEhlYWRlcjogQ29udGVudC1MZW5ndGggPSA0MTINCjE3Mzk2IFsgICAgMV0gTWFy IDE5IDIyOjM3OjMyIFJlcXVlc3QgSGVhZGVyOiBDb250ZW50LVR5cGUgPSB0ZXh0L2NhbGVuZGFy OyBjaGFyc2V0PXV0Zi04DQoxNzM5NiBbICAgIDFdIE1hciAxOSAyMjozNzozMiBSZXF1ZXN0IEhl YWRlcjogSG9zdCA9IGRhdi5kZXYudXNhLm5ldDo4MA0KMTczOTYgWyAgICAxXSBNYXIgMTkgMjI6 Mzc6MzIgUmVxdWVzdCBIZWFkZXI6IElmLU5vbmUtTWF0Y2ggPSAqDQoxNzM5NiBbICAgIDFdIE1h ciAxOSAyMjozNzozMiBSZXF1ZXN0IEhlYWRlcjogVXNlci1BZ2VudCA9IEJpb25pY01lc3NhZ2Uu bmV0IEdyb3VwREFWIHswLjk7SmF2YX0NCjE3Mzk2IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMyIEFj Y291bnRJRDogMjIwMDMwMDc2OTQwMDANCjE3Mzk2IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMyIE9w ZW5lZCB0ZW1wIGZpbGUgL3Zhci90bXAvZGF2SDRhRy5ILiAgUmVhZGluZyBkYXRhLi4uDQoxNzM5 NiBbICAgIDFdIE1hciAxOSAyMjozNzozMiBGaW5pc2hlZCByZWFkaW5nIGRhdGEuDQoxNzM5NiBb ICAgIDFdIE1hciAxOSAyMjozNzozMiBVSUQgZm91bmQ6IDAwMDAwMDAwMjU5QURENDQ3RTVFOEY0 Mjg3NzUyNTk2RUUzNjgzNDUyNDQ2MjAwMA0KMTczOTYgWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzIg Q2FsbGluZyBDYWxlbmRhci5EYXZJbXBvcnRFdmVudA0KMTczOTYgWyAgICAxXSBNYXIgMTkgMjI6 Mzc6MzIgRG9uZSBDYWxsaW5nIENhbGVuZGFyLkRhdkltcG9ydEV2ZW50DQoxNzM5NiBbICAgIDFd IE1hciAxOSAyMjozNzozMiBUaGluayB3ZSBzdWNjZWVkZWQgd2l0aCB0aGUgSW1wb3J0DQoxNzM5 NiBbICAgIDFdIE1hciAxOSAyMjozNzozMiBSZXNwb25zZSBIZWFkZXI6IFgtUG93ZXJlZC1CeSA9 IFBIUC81LjIuMA0KMTczOTYgWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzIgUmVzcG9uc2UgSGVhZGVy OiBYLURhdi1Qb3dlcmVkLUJ5LWNiID0gUEhQIGNsYXNzOiBIVFRQX1dlYkRBVl9TZXJ2ZXJfR1JP VVBEQVZEQg0KMTczOTYgWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzIgUmVzcG9uc2UgSGVhZGVyOiBl dGFnID0gIjEwMDAwMTY4ODQzMjEiDQoxNzM5NiBbICAgIDFdIE1hciAxOSAyMjozNzozMiBSZXNw b25zZSBIZWFkZXI6IExvY2F0aW9uID0gaHR0cDovL2Rhdi5kZXYudXNhLm5ldDo4MC9ncm91cGRh di9zaGFkMnNAZGV2bzA0MDIuZGV2LnVzYS5uZXQvQ2FsZW5kYXIvMDAwMDAwMDAyNTlBREQ0NDdF NUU4RjQyODc3NTI1OTZFRTM2ODM0NTI0NDYyMDAwLmljcw0KMTczOTYgWyAgICAxXSBNYXIgMTkg MjI6Mzc6MzIgUmVzcG9uc2UgSGVhZGVyOiBYLVdlYkRBVi1TdGF0dXMgPSAyMDEgQ3JlYXRlZA0K MTczOTYgWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzIgRG9uZTogUFVUICAgICAgL2dyb3VwZGF2L3No YWQyc0BkZXZvMDQwMi5kZXYudXNhLm5ldC9DYWxlbmRhci9uZXcuaWNzDQoxNzQ2MCBbICAgIDFd IE1hciAxOSAyMjozNzozMiBTdGFydDogR0VUICAgICAgL2dyb3VwZGF2L3NoYWQyc0BkZXZvMDQw Mi5kZXYudXNhLm5ldC9DYWxlbmRhci8wMDAwMDAwMDI1OUFERDQ0N0U1RThGNDI4Nzc1MjU5NkVF MzY4MzQ1MjQ0NjIwMDAuaWNzDQoxNzQ2MCBbICAgIDFdIE1hciAxOSAyMjozNzozMiBSZXF1ZXN0 IEhlYWRlcjogQXV0aG9yaXphdGlvbiA9IEJhc2ljIGMyaGhaREp6UUdSbGRtOHdOREF5TG1SbGRp NTFjMkV1Ym1WME9tRmlZekV5TXc9PQ0KMTc0NjAgWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzIgUmVx dWVzdCBIZWFkZXI6IENvbnRlbnQtTGVuZ3RoID0gMA0KMTc0NjAgWyAgICAxXSBNYXIgMTkgMjI6 Mzc6MzIgUmVxdWVzdCBIZWFkZXI6IEhvc3QgPSBkYXYuZGV2LnVzYS5uZXQ6ODANCjE3NDYwIFsg ICAgMV0gTWFyIDE5IDIyOjM3OjMyIFJlcXVlc3QgSGVhZGVyOiBVc2VyLUFnZW50ID0gQmlvbmlj TWVzc2FnZS5uZXQgR3JvdXBEQVYgezAuOTtKYXZhfQ0KMTc0NjAgWyAgICAxXSBNYXIgMTkgMjI6 Mzc6MzMgQWNjb3VudElEOiAyMjAwMzAwNzY5NDAwMA0KMTc0NjAgWyAgICAxXSBNYXIgMTkgMjI6 Mzc6MzMgUmVzcG9uc2UgSGVhZGVyOiBYLVBvd2VyZWQtQnkgPSBQSFAvNS4yLjANCjE3NDYwIFsg ICAgMV0gTWFyIDE5IDIyOjM3OjMzIFJlc3BvbnNlIEhlYWRlcjogWC1EYXYtUG93ZXJlZC1CeS1j YiA9IFBIUCBjbGFzczogSFRUUF9XZWJEQVZfU2VydmVyX0dST1VQREFWREINCjE3NDYwIFsgICAg MV0gTWFyIDE5IDIyOjM3OjMzIFJlc3BvbnNlIEhlYWRlcjogTGFzdC1tb2RpZmllZCA9IE1vbiwg MTkgTWFyIDIwMDcgMjI6Mzc6MzIgR01UDQoxNzQ2MCBbICAgIDFdIE1hciAxOSAyMjozNzozMyBS ZXNwb25zZSBIZWFkZXI6IGV0YWcgPSAiMTAwMDAxNjg4NDMyMSINCjE3NDYwIFsgICAgMV0gTWFy IDE5IDIyOjM3OjMzIFJlc3BvbnNlIEhlYWRlcjogQ29udGVudC1sZW5ndGggPSA0MTINCjE3NDYw IFsgICAgMV0gTWFyIDE5IDIyOjM3OjMzIFJlc3BvbnNlIEhlYWRlcjogWC1XZWJEQVYtU3RhdHVz ID0gMjAwIE9LDQoxNzQ2MCBbICAgIDFdIE1hciAxOSAyMjozNzozMyBSZXNwb25zZSBIZWFkZXI6 IENvbm5lY3Rpb24gPSBjbG9zZQ0KMTc0NjAgWyAgICAxXSBNYXIgMTkgMjI6Mzc6MzMgUmVzcG9u c2UgSGVhZGVyOiBDb250ZW50LVR5cGUgPSB0ZXh0L2NhbGVuZGFyOyBjaGFyc2V0PXV0Zi04DQox NzQ2MCBbICAgIDFdIE1hciAxOSAyMjozNzozMyBEb25lOiBHRVQgICAgICAvZ3JvdXBkYXYvc2hh ZDJzQGRldm8wNDAyLmRldi51c2EubmV0L0NhbGVuZGFyLzAwMDAwMDAwMjU5QURENDQ3RTVFOEY0 Mjg3NzUyNTk2RUUzNjgzNDUyNDQ2MjAwMC5pY3MNCg0KDQoNCg0KbmV0LmJpb25pY21lc3NhZ2Uu Z3JvdXBkYXYuZ3JvdXBEQVYNCg0KDQppbml0DQoNCg0KR3JvdXBEQVYgY2xpZW50IGluaXQoKQ0K DQoNCm5ldC5iaW9uaWNtZXNzYWdlLm9iamVjdHMuSUNhbGVuZGFyT2JqZWN0U3RvcmUNCg0KDQpz dGFydFN5bmMNCg0KDQpTeW5jIHN0YXJ0ZWQuLi4uDQoNCg0KbmV0LmJpb25pY21lc3NhZ2UuZ3Jv dXBkYXYuZ3JvdXBEQVYNCg0KDQpzZW5kTm9uS2VlcEFsaXZlUmVxdWVzdA0KDQoNCldlIHNlbnQ6 DQpQUk9QRklORCAvZ3JvdXBkYXYvc2hhZDJzQGRldm8wNDAyLmRldi51c2EubmV0L0NhbGVuZGFy LyBIVFRQLzEuMQ0KQ2FjaGUtY29udHJvbDogbm8tY2FjaGUNClByYWdtYTogbm8tY2FjaGUNCkFj Y2VwdC1MYW5ndWFnZTogZW4NCkF1dGhvcml6YXRpb246IEJhc2ljIGMyaGhaREp6UUdSbGRtOHdO REF5TG1SbGRpNTFjMkV1Ym1WME9tRmlZekV5TXc9PQ0KQ29udGVudC1MZW5ndGg6IDk1DQpIb3N0 OiBkYXYuZGV2LnVzYS5uZXQ6ODANCkRlcHRoOiAxDQpDb250ZW50LVR5cGU6IHRleHQveG1sO2No YXJzZXQ9dXRmLTgNCkFjY2VwdDogdGV4dC8qDQoNCjw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rp bmc9InV0Zi04Ij8+PHByb3BmaW5kIHhtbG5zPSJEQVY6Ij48cHJvcD48Z2V0ZXRhZy8+PC9wcm9w PjwvcHJvcGZpbmQ+DQoNCg0KV2UgZ290Og0KSFRUUC8xLjEgMjA3IE11bHRpLVN0YXR1cw0KRGF0 ZTogTW9uLCAxOSBNYXIgMjAwNyAyMjozNzozMSBHTVQNClNlcnZlcjogQXBhY2hlLzEuMy4zNyAo VW5peCkgbW9kX2Zhc3RjZ2kvMi40LjAgbW9kX3NzbC8yLjguMjggT3BlblNTTC8wLjkuN2UgUEhQ LzUuMi4wDQpYLVBvd2VyZWQtQnk6IFBIUC81LjIuMA0KWC1EYXYtUG93ZXJlZC1CeS1jYjogUEhQ IGNsYXNzOiBIVFRQX1dlYkRBVl9TZXJ2ZXJfR1JPVVBEQVZEQg0KWC1XZWJEQVYtU3RhdHVzOiAy MDcgTXVsdGktU3RhdHVzDQpDb250ZW50LWxlbmd0aDogODcNCkNvbm5lY3Rpb246IGNsb3NlDQpD b250ZW50LVR5cGU6IHRleHQveG1sOyBjaGFyc2V0PSJ1dGYtOCINCg0KPD94bWwgdmVyc2lvbj0i MS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjxEOm11bHRpc3RhdHVzIHhtbG5zOkQ9IkRBVjoiPg0K PC9EOm11bHRpc3RhdHVzPg0KDQouLi4uaW4gMTcxbXMNCg0KDQpXZSBzZW50Og0KUFVUIC9ncm91 cGRhdi9zaGFkMnNAZGV2bzA0MDIuZGV2LnVzYS5uZXQvQ2FsZW5kYXIvbmV3LmljcyBIVFRQLzEu MQ0KQ29udGVudC1UeXBlOiB0ZXh0L2NhbGVuZGFyOyBjaGFyc2V0PXV0Zi04DQpJZi1Ob25lLU1h dGNoOiAqDQpBdXRob3JpemF0aW9uOiBCYXNpYyBjMmhoWkRKelFHUmxkbTh3TkRBeUxtUmxkaTUx YzJFdWJtVjBPbUZpWXpFeU13PT0NCkNvbnRlbnQtTGVuZ3RoOiA0MTINClVzZXItQWdlbnQ6IEJp b25pY01lc3NhZ2UubmV0IEdyb3VwREFWIHswLjk7SmF2YX0NCkhvc3Q6IGRhdi5kZXYudXNhLm5l dDo4MA0KDQpCRUdJTjpWQ0FMRU5EQVINClBST0RJRDotLy9CaW9uaWNNZXNzYWdlIEZ1bmFtYm9s IENvbm5lY3Rvci8vZnVuYW1ib2wyaWNhbDRqY29udmVydC8vRU4NClZFUlNJT046Mi4wDQpCRUdJ TjpWRVZFTlQNCkRUU1RBTVA6MjAwNzAzMTlUMjIzNjIyWg0KRFRTVEFSVDoyMDA3MDMxOVQyMjAw MDBaDQpEVEVORDoyMDA3MDMxOVQyMzAwMDBaDQpTVU1NQVJZOkNyZWF0ZWQgaW4gT3V0bG9vaw0K VUlEOjAwMDAwMDAwMjU5QURENDQ3RTVFOEY0Mjg3NzUyNTk2RUUzNjgzNDUyNDQ2MjAwMA0KTEFT VC1NT0RJRklFRDoyMDA3MDMxOVQyMjM2MjJaDQpERVNDUklQVElPTjoNCkNMQVNTOlBVQkxJQw0K T1JHQU5JWkVSOg0KUFJJT1JJVFk6NQ0KVFJBTlNQOk9QQVFVRQ0KU0VRVUVOQ0U6MA0KRU5EOlZF VkVOVA0KRU5EOlZDQUxFTkRBUg0KDQoNCg0KV2UgZ290Og0KSFRUUC8xLjEgMjAxIENyZWF0ZWQN CkRhdGU6IE1vbiwgMTkgTWFyIDIwMDcgMjI6Mzc6MzIgR01UDQpTZXJ2ZXI6IEFwYWNoZS8xLjMu MzcgKFVuaXgpIG1vZF9mYXN0Y2dpLzIuNC4wIG1vZF9zc2wvMi44LjI4IE9wZW5TU0wvMC45Ljdl IFBIUC81LjIuMA0KWC1Qb3dlcmVkLUJ5OiBQSFAvNS4yLjANClgtRGF2LVBvd2VyZWQtQnktY2I6 IFBIUCBjbGFzczogSFRUUF9XZWJEQVZfU2VydmVyX0dST1VQREFWREINCmV0YWc6ICIxMDAwMDE2 ODg0MzIxIg0KTG9jYXRpb246IGh0dHA6Ly9kYXYuZGV2LnVzYS5uZXQ6ODAvZ3JvdXBkYXYvc2hh ZDJzQGRldm8wNDAyLmRldi51c2EubmV0L0NhbGVuZGFyLzAwMDAwMDAwMjU5QURENDQ3RTVFOEY0 Mjg3NzUyNTk2RUUzNjgzNDUyNDQ2MjAwMC5pY3MNClgtV2ViREFWLVN0YXR1czogMjAxIENyZWF0 ZWQNCkNvbm5lY3Rpb246IGNsb3NlDQpUcmFuc2Zlci1FbmNvZGluZzogY2h1bmtlZA0KQ29udGVu dC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgNCg0KMA0KDQoNCi4uLi5pbiA2MDhtcw0K DQoNCnBvc3RPYmplY3QNCg0KDQpXZSBnb3RIVFRQLzEuMSAyMDEgQ3JlYXRlZA0KRGF0ZTogTW9u LCAxOSBNYXIgMjAwNyAyMjozNzozMiBHTVQNClNlcnZlcjogQXBhY2hlLzEuMy4zNyAoVW5peCkg bW9kX2Zhc3RjZ2kvMi40LjAgbW9kX3NzbC8yLjguMjggT3BlblNTTC8wLjkuN2UgUEhQLzUuMi4w DQpYLVBvd2VyZWQtQnk6IFBIUC81LjIuMA0KWC1EYXYtUG93ZXJlZC1CeS1jYjogUEhQIGNsYXNz OiBIVFRQX1dlYkRBVl9TZXJ2ZXJfR1JPVVBEQVZEQg0KZXRhZzogIjEwMDAwMTY4ODQzMjEiDQpM b2NhdGlvbjogaHR0cDovL2Rhdi5kZXYudXNhLm5ldDo4MC9ncm91cGRhdi9zaGFkMnNAZGV2bzA0 MDIuZGV2LnVzYS5uZXQvQ2FsZW5kYXIvMDAwMDAwMDAyNTlBREQ0NDdFNUU4RjQyODc3NTI1OTZF RTM2ODM0NTI0NDYyMDAwLmljcw0KWC1XZWJEQVYtU3RhdHVzOiAyMDEgQ3JlYXRlZA0KQ29ubmVj dGlvbjogY2xvc2UNClRyYW5zZmVyLUVuY29kaW5nOiBjaHVua2VkDQpDb250ZW50LVR5cGU6IHRl eHQvaHRtbDsgY2hhcnNldD1VVEYtOA0KDQowDQoNCg0KDQoNCldlIHNlbnQ6DQpHRVQgL2dyb3Vw ZGF2L3NoYWQyc0BkZXZvMDQwMi5kZXYudXNhLm5ldC9DYWxlbmRhci8wMDAwMDAwMDI1OUFERDQ0 N0U1RThGNDI4Nzc1MjU5NkVFMzY4MzQ1MjQ0NjIwMDAuaWNzIEhUVFAvMS4xDQpBdXRob3JpemF0 aW9uOiBCYXNpYyBjMmhoWkRKelFHUmxkbTh3TkRBeUxtUmxkaTUxYzJFdWJtVjBPbUZpWXpFeU13 PT0NCkNvbnRlbnQtTGVuZ3RoOiAwDQpVc2VyLUFnZW50OiBCaW9uaWNNZXNzYWdlLm5ldCBHcm91 cERBViB7MC45O0phdmF9DQpIb3N0OiBkYXYuZGV2LnVzYS5uZXQ6ODANCg0KDQoNCg0KDQoNCldl IGdvdDoNCkhUVFAvMS4xIDIwMCBPSw0KRGF0ZTogTW9uLCAxOSBNYXIgMjAwNyAyMjozNzozMiBH TVQNClNlcnZlcjogQXBhY2hlLzEuMy4zNyAoVW5peCkgbW9kX2Zhc3RjZ2kvMi40LjAgbW9kX3Nz bC8yLjguMjggT3BlblNTTC8wLjkuN2UgUEhQLzUuMi4wDQpYLVBvd2VyZWQtQnk6IFBIUC81LjIu MA0KWC1EYXYtUG93ZXJlZC1CeS1jYjogUEhQIGNsYXNzOiBIVFRQX1dlYkRBVl9TZXJ2ZXJfR1JP VVBEQVZEQg0KTGFzdC1tb2RpZmllZDogTW9uLCAxOSBNYXIgMjAwNyAyMjozNzozMiBHTVQNCmV0 YWc6ICIxMDAwMDE2ODg0MzIxIg0KQ29udGVudC1sZW5ndGg6IDQxMg0KWC1XZWJEQVYtU3RhdHVz OiAyMDAgT0sNCkNvbm5lY3Rpb246IGNsb3NlDQpDb250ZW50LVR5cGU6IHRleHQvY2FsZW5kYXI7 IGNoYXJzZXQ9dXRmLTgNCg0KQkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vQmlvbmljTWVzc2Fn ZSBGdW5hbWJvbCBDb25uZWN0b3IvL2Z1bmFtYm9sMmljYWw0amNvbnZlcnQvL0VODQpWRVJTSU9O OjIuMA0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMDcwMzE5VDIyMzYyMloNCkRUU1RBUlQ6MjAw NzAzMTlUMjIwMDAwWg0KRFRFTkQ6MjAwNzAzMTlUMjMwMDAwWg0KU1VNTUFSWTpDcmVhdGVkIGlu IE91dGxvb2sNClVJRDowMDAwMDAwMDI1OUFERDQ0N0U1RThGNDI4Nzc1MjU5NkVFMzY4MzQ1MjQ0 NjIwMDANCkxBU1QtTU9ESUZJRUQ6MjAwNzAzMTlUMjIzNjIyWg0KREVTQ1JJUFRJT046DQpDTEFT UzpQVUJMSUMNCk9SR0FOSVpFUjoNClBSSU9SSVRZOjUNClRSQU5TUDpPUEFRVUUNClNFUVVFTkNF OjANCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg0KLi4uLmluIDE1Mm1zDQoNCg0KbmV0LmJp b25pY21lc3NhZ2Uub2JqZWN0cy5JQ2FsZW5kYXJPYmplY3RTdG9yZQ0KDQoNCmdldE9iamVjdEZy b21TdG9yZQ0KDQoNCk9iamVjdCAwMDAwMDAwMDI1OUFERDQ0N0U1RThGNDI4Nzc1MjU5NkVFMzY4 MzQ1MjQ0NjIwMDBoYXMgYmVlbiByZXRyaWV2ZWQgZnJvbSBzdG9yZQ0KDQoNCnByaW50RGVidWdS ZXBvcnQNCg0KDQotLS0tLS0tLS0tDQpVSUQ6MDAwMDAwMDAyNTlBREQ0NDdFNUU4RjQyODc3NTI1 OTZFRTM2ODM0NTI0NDYyMDAwDQpVUkw6aHR0cDovL2Rhdi5kZXYudXNhLm5ldDo4MC9ncm91cGRh di9zaGFkMnNAZGV2bzA0MDIuZGV2LnVzYS5uZXQvQ2FsZW5kYXIvMDAwMDAwMDAyNTlBREQ0NDdF NUU4RjQyODc3NTI1OTZFRTM2ODM0NTI0NDYyMDAwLmljcw0KRVRBRzoiMTAwMDAxNjg4NDMyMSIN Ck5BTUU6Q3JlYXRlZCBpbiBPdXRsb29rDQpEVFNUQVJUOjExNzQzNDE2MDANCkRURU5EOjExNzQz NDUyMDANCkRBVEEgRk9MTE9XUzoNCkJFR0lOOlZDQUxFTkRBUg0KUFJPRElEOi0vL0Jpb25pY01l c3NhZ2UgRnVuYW1ib2wgQ29ubmVjdG9yLy9mdW5hbWJvbDJpY2FsNGpjb252ZXJ0Ly9FTg0KVkVS U0lPTjoyLjANCkJFR0lOOlZFVkVOVA0KRFRTVEFNUDoyMDA3MDMxOVQyMjM2MjJaDQpEVFNUQVJU OjIwMDcwMzE5VDIyMDAwMFoNCkRURU5EOjIwMDcwMzE5VDIzMDAwMFoNClNVTU1BUlk6Q3JlYXRl ZCBpbiBPdXRsb29rDQpVSUQ6MDAwMDAwMDAyNTlBREQ0NDdFNUU4RjQyODc3NTI1OTZFRTM2ODM0 NTI0NDYyMDAwDQpMQVNULU1PRElGSUVEOjIwMDcwMzE5VDIyMzYyMloNCkRFU0NSSVBUSU9OOg0K Q0xBU1M6UFVCTElDDQpPUkdBTklaRVI6DQpQUklPUklUWTo1DQpUUkFOU1A6T1BBUVVFDQpTRVFV RU5DRTowDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQotLS0tLS0tLS0tDQpPYmplY3RzIGFk ZGVkIHRvIHN0b3JlOiANCk9iamVjdHMgdXBkYXRlZCBmcm9tIHNlcnZlcjogDQpPYmplY3RzIGRl bGV0ZWQgZnJvbSBzdG9yZTogDQpPYmplY3RzIGFkZGVkIHRvIHRoZSBzZXJ2ZXI6IA0KU0E6ICAg MDAwMDAwMDAyNTlBREQ0NDdFNUU4RjQyODc3NTI1OTZFRTM2ODM0NTI0NDYyMDAwDQpPYmplY3Rz IG1lcmdlZCB0byBzZXJ2ZXI6IA0KT2JqZWN0cyBkZWxldGVkIGZyb20gc2VydmVyOiANCg0KDQoN Cg0KDQoxNzYzOSBbICAgIDFdIE1hciAxOSAyMjo0MToyMiBTdGFydDogUFJPUEZJTkQgL2dyb3Vw ZGF2L3NoYWQyc0BkZXZvMDQwMi5kZXYudXNhLm5ldC9DYWxlbmRhci8NCjE3NjM5IFsgICAgMV0g TWFyIDE5IDIyOjQxOjIyIFJlcXVlc3QgSGVhZGVyOiBBY2NlcHQgPSB0ZXh0LyoNCjE3NjM5IFsg ICAgMV0gTWFyIDE5IDIyOjQxOjIyIFJlcXVlc3QgSGVhZGVyOiBBY2NlcHQtTGFuZ3VhZ2UgPSBl bg0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIgUmVxdWVzdCBIZWFkZXI6IEF1dGhvcml6 YXRpb24gPSBCYXNpYyBjMmhoWkRKelFHUmxkbTh3TkRBeUxtUmxkaTUxYzJFdWJtVjBPbUZpWXpF eU13PT0NCjE3NjM5IFsgICAgMV0gTWFyIDE5IDIyOjQxOjIyIFJlcXVlc3QgSGVhZGVyOiBDYWNo ZS1jb250cm9sID0gbm8tY2FjaGUNCjE3NjM5IFsgICAgMV0gTWFyIDE5IDIyOjQxOjIyIFJlcXVl c3QgSGVhZGVyOiBDb250ZW50LUxlbmd0aCA9IDk1DQoxNzYzOSBbICAgIDFdIE1hciAxOSAyMjo0 MToyMiBSZXF1ZXN0IEhlYWRlcjogQ29udGVudC1UeXBlID0gdGV4dC94bWw7Y2hhcnNldD11dGYt OA0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIgUmVxdWVzdCBIZWFkZXI6IERlcHRoID0g MQ0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIgUmVxdWVzdCBIZWFkZXI6IEhvc3QgPSBk YXYuZGV2LnVzYS5uZXQ6ODANCjE3NjM5IFsgICAgMV0gTWFyIDE5IDIyOjQxOjIyIFJlcXVlc3Qg SGVhZGVyOiBQcmFnbWEgPSBuby1jYWNoZQ0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIg QWNjb3VudElEOiAyMjAwMzAwNzY5NDAwMA0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIg UmVzcG9uc2UgSGVhZGVyOiBYLVBvd2VyZWQtQnkgPSBQSFAvNS4yLjANCjE3NjM5IFsgICAgMV0g TWFyIDE5IDIyOjQxOjIyIFJlc3BvbnNlIEhlYWRlcjogWC1EYXYtUG93ZXJlZC1CeS1jYiA9IFBI UCBjbGFzczogSFRUUF9XZWJEQVZfU2VydmVyX0dST1VQREFWREINCjE3NjM5IFsgICAgMV0gTWFy IDE5IDIyOjQxOjIyIFJlc3BvbnNlIEhlYWRlcjogWC1XZWJEQVYtU3RhdHVzID0gMjA3IE11bHRp LVN0YXR1cw0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIgUmVzcG9uc2UgSGVhZGVyOiBD b250ZW50LWxlbmd0aCA9IDQ1OQ0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIgUmVzcG9u c2UgSGVhZGVyOiBDb25uZWN0aW9uID0gY2xvc2UNCjE3NjM5IFsgICAgMV0gTWFyIDE5IDIyOjQx OjIyIFJlc3BvbnNlIEhlYWRlcjogQ29udGVudC1UeXBlID0gdGV4dC94bWw7IGNoYXJzZXQ9InV0 Zi04Ig0KMTc2MzkgWyAgICAxXSBNYXIgMTkgMjI6NDE6MjIgRG9uZTogUFJPUEZJTkQgL2dyb3Vw ZGF2L3NoYWQyc0BkZXZvMDQwMi5kZXYudXNhLm5ldC9DYWxlbmRhci8NCg0KDQoNCg0KDQoNCm5l dC5iaW9uaWNtZXNzYWdlLmdyb3VwZGF2Lmdyb3VwREFWDQoNCg0KaW5pdA0KDQoNCkdyb3VwREFW IGNsaWVudCBpbml0KCkNCg0KDQpuZXQuYmlvbmljbWVzc2FnZS5vYmplY3RzLklDYWxlbmRhck9i amVjdFN0b3JlDQoNCg0Kc3RhcnRTeW5jDQoNCg0KU3luYyBzdGFydGVkLi4uLg0KDQoNCm5ldC5i aW9uaWNtZXNzYWdlLmdyb3VwZGF2Lmdyb3VwREFWDQoNCg0Kc2VuZE5vbktlZXBBbGl2ZVJlcXVl c3QNCg0KDQpXZSBzZW50Og0KUFJPUEZJTkQgL2dyb3VwZGF2L3NoYWQyc0BkZXZvMDQwMi5kZXYu dXNhLm5ldC9DYWxlbmRhci8gSFRUUC8xLjENCkNhY2hlLWNvbnRyb2w6IG5vLWNhY2hlDQpQcmFn bWE6IG5vLWNhY2hlDQpBY2NlcHQtTGFuZ3VhZ2U6IGVuDQpBdXRob3JpemF0aW9uOiBCYXNpYyBj MmhoWkRKelFHUmxkbTh3TkRBeUxtUmxkaTUxYzJFdWJtVjBPbUZpWXpFeU13PT0NCkNvbnRlbnQt TGVuZ3RoOiA5NQ0KSG9zdDogZGF2LmRldi51c2EubmV0OjgwDQpEZXB0aDogMQ0KQ29udGVudC1U eXBlOiB0ZXh0L3htbDtjaGFyc2V0PXV0Zi04DQpBY2NlcHQ6IHRleHQvKg0KDQo8P3htbCB2ZXJz aW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtOCI/Pjxwcm9wZmluZCB4bWxucz0iREFWOiI+PHByb3A+ PGdldGV0YWcvPjwvcHJvcD48L3Byb3BmaW5kPg0KDQoNCldlIGdvdDoNCkhUVFAvMS4xIDIwNyBN dWx0aS1TdGF0dXMNCkRhdGU6IE1vbiwgMTkgTWFyIDIwMDcgMjI6NDE6MjIgR01UDQpTZXJ2ZXI6 IEFwYWNoZS8xLjMuMzcgKFVuaXgpIG1vZF9mYXN0Y2dpLzIuNC4wIG1vZF9zc2wvMi44LjI4IE9w ZW5TU0wvMC45LjdlIFBIUC81LjIuMA0KWC1Qb3dlcmVkLUJ5OiBQSFAvNS4yLjANClgtRGF2LVBv d2VyZWQtQnktY2I6IFBIUCBjbGFzczogSFRUUF9XZWJEQVZfU2VydmVyX0dST1VQREFWREINClgt V2ViREFWLVN0YXR1czogMjA3IE11bHRpLVN0YXR1cw0KQ29udGVudC1sZW5ndGg6IDQ1OQ0KQ29u bmVjdGlvbjogY2xvc2UNCkNvbnRlbnQtVHlwZTogdGV4dC94bWw7IGNoYXJzZXQ9InV0Zi04Ig0K DQo8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtOCI/Pg0KPEQ6bXVsdGlzdGF0dXMg eG1sbnM6RD0iREFWOiI+DQogPEQ6cmVzcG9uc2UgeG1sbnM6bnMwPSJ1cm46dXVpZDpjMmY0MTAx MC02NWIzLTExZDEtYTI5Zi0wMGFhMDBjMTQ4ODIvIj4NCiAgPEQ6aHJlZj5odHRwOi8vZGF2LmRl di51c2EubmV0OjgwL2dyb3VwZGF2L3NoYWQyc0BkZXZvMDQwMi5kZXYudXNhLm5ldC9DYWxlbmRh ci8wMDAwMDAwMDI1OUFERDQ0N0U1RThGNDI4Nzc1MjU5NkVFMzY4MzQ1MjQ0NjIwMDAuaWNzPC9E OmhyZWY+DQogIDxEOnByb3BzdGF0Pg0KICAgPEQ6cHJvcD4NCiAgICAgPEQ6Z2V0ZXRhZz4iMTAw MDAxNjg4NDMyMSI8L0Q6Z2V0ZXRhZz4NCiAgIDwvRDpwcm9wPg0KICAgPEQ6c3RhdHVzPkhUVFAv MS4xIDIwMCBPSzwvRDpzdGF0dXM+DQogIDwvRDpwcm9wc3RhdD4NCiA8L0Q6cmVzcG9uc2U+DQo8 L0Q6bXVsdGlzdGF0dXM+DQoNCi4uLi5pbiAxNzBtcw0KDQoNCm5ldC5iaW9uaWNtZXNzYWdlLm9i amVjdHMuSUNhbGVuZGFyT2JqZWN0U3RvcmUNCg0KDQpzdGFydFN5bmMNCg0KDQpXZSBoYXZlIHRo ZSBVUkw6IGh0dHA6Ly9kYXYuZGV2LnVzYS5uZXQ6ODAvZ3JvdXBkYXYvc2hhZDJzQGRldm8wNDAy LmRldi51c2EubmV0L0NhbGVuZGFyLzAwMDAwMDAwMjU5QURENDQ3RTVFOEY0Mjg3NzUyNTk2RUUz NjgzNDUyNDQ2MjAwMC5pY3MNCg0KDQpnZXRPYmplY3RGcm9tU3RvcmUNCg0KDQpXZSBhcmUgY29u c3RydWN0aW5nIGFuIG9iamVjdCBmb3IgMDAwMDAwMDAyNTlBREQ0NDdFNUU4RjQyODc3NTI1OTZF RTM2ODM0NTI0NDYyMDAwDQoNCg0KcHJpbnREZWJ1Z1JlcG9ydA0KDQoNCi0tLS0tLS0tLS0NClVJ RDowMDAwMDAwMDI1OUFERDQ0N0U1RThGNDI4Nzc1MjU5NkVFMzY4MzQ1MjQ0NjIwMDANClVSTDpo dHRwOi8vZGF2LmRldi51c2EubmV0OjgwL2dyb3VwZGF2L3NoYWQyc0BkZXZvMDQwMi5kZXYudXNh Lm5ldC9DYWxlbmRhci8wMDAwMDAwMDI1OUFERDQ0N0U1RThGNDI4Nzc1MjU5NkVFMzY4MzQ1MjQ0 NjIwMDAuaWNzDQpFVEFHOiIxMDAwMDE2ODg0MzIxIg0KTkFNRTpDcmVhdGVkIGluIE91dGxvb2sN CkRUU1RBUlQ6MTE3NDM0MTYwMA0KRFRFTkQ6MTE3NDM0NTIwMA0KREFUQSBGT0xMT1dTOg0KQkVH SU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vQmlvbmljTWVzc2FnZSBGdW5hbWJvbCBDb25uZWN0b3Iv L2Z1bmFtYm9sMmljYWw0amNvbnZlcnQvL0VODQpWRVJTSU9OOjIuMA0KQkVHSU46VkVWRU5UDQpE VFNUQU1QOjIwMDcwMzE5VDIyMzYyMloNCkRUU1RBUlQ6MjAwNzAzMTlUMjIwMDAwWg0KRFRFTkQ6 MjAwNzAzMTlUMjMwMDAwWg0KU1VNTUFSWTpDcmVhdGVkIGluIE91dGxvb2sNClVJRDowMDAwMDAw MDI1OUFERDQ0N0U1RThGNDI4Nzc1MjU5NkVFMzY4MzQ1MjQ0NjIwMDANCkxBU1QtTU9ESUZJRUQ6 MjAwNzAzMTlUMjIzNjIyWg0KREVTQ1JJUFRJT046DQpDTEFTUzpQVUJMSUMNCk9SR0FOSVpFUjoN ClBSSU9SSVRZOjUNClRSQU5TUDpPUEFRVUUNClNFUVVFTkNFOjANCkVORDpWRVZFTlQNCkVORDpW Q0FMRU5EQVINCi0tLS0tLS0tLS0NCk9iamVjdHMgYWRkZWQgdG8gc3RvcmU6IA0KT2JqZWN0cyB1 cGRhdGVkIGZyb20gc2VydmVyOiANCk9iamVjdHMgZGVsZXRlZCBmcm9tIHN0b3JlOiANCk9iamVj dHMgYWRkZWQgdG8gdGhlIHNlcnZlcjogDQpPYmplY3RzIG1lcmdlZCB0byBzZXJ2ZXI6IA0KT2Jq ZWN0cyBkZWxldGVkIGZyb20gc2VydmVyOiANCg0KDQo= ------_=_NextPart_001_01C76A79.37479694-- From groupdav@opengroupware.org Tue Mar 20 05:31:06 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Tue, 20 Mar 2007 16:31:06 +1100 Subject: [GroupDAV] Not sync'ing updates from Outlook to Server In-Reply-To: Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3257253069_37133 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The last storelog.html shows that the modifications you did in Outlook haven=B9t reached the connector at all. Set Funambol=B9s log level to ALL and then repeat the process. You=B9ll probabl= y see an exception being thrown once you reach step 4. That should be enough data. I=B9ll try repeating this myself soon. You could also try setting the connector to output in the SIF data format instead =AD enter text/x-s4j-sife when creating an event and configure the Funambol outlook client to use that instead of vCal. If that works, then it= s a parser bug in Funambol. On 20/3/07 9:52 AM, "Tews, Shad" wrote: > Here is what I am testing and what I am seeing. > =20 > 1) I create an event in Outlook. > 2) I sync the event to our server where it does appear in the Calendar. I= see > all the commands go through and they look ok. > 3) I add a location to the event in Outlook. > 4) I try and sync again but the location does not appear on the server. > =20 > I cut and pasted the following into this log file. > =20 > First part > ------------ > Our log file showing the PROPFIND, PUT, and GET commands. > =20 > Second Part > ---------------- > The storelog.html file for the PROPFIND, PUT, and GET > =20 > Third Part > ------------- > Our log file showing just a PROPFIND coming through after I updated the > location and tried to sync > =20 > Fourth Part > --------------- > The storelog.html file with the sync after I updated the location. > =20 > It seems like it does not recognize the fact that there was an update mad= e at > the client side. If I delete the event and sync it does delete the event = on > the server. Let me know if you need any other logs. > =20 > thanks, > Shad >=20 >=20 >=20 > =20 >=20 > =20 >=20 --B_3257253069_37133 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [GroupDAV] Not sync'ing updates from Outlook to Server The l= ast storelog.html shows that the modifications you did in Outlook haven̵= 7;t reached the connector at all.

Set Funambol’s log level to ALL and then repeat the process. You̵= 7;ll probably see an exception being thrown once you reach step 4. That shou= ld be enough data. I’ll try repeating this myself soon.

You could also try setting the connector to output in the SIF data format i= nstead – enter text/x-s4j-sife when creating an event and configure th= e Funambol outlook client to use that instead of vCal. If that works, then i= ts a parser bug in Funambol.

On 20/3/07 9:52 AM, "Tews, Shad" <Shad.Tews@corpx.usa.net> = wrote:

Here is what I am testing and what I am seeing.
 
1) I create an event in Outlook.
2) I sync the event to our server where it does appear in the Calendar. I s= ee all the commands go through and they look ok.
3) I add a location to the event in Outlook.
4) I try and sync again but the location does not appear on the server.
 
I cut and pasted the following into this log file.
 
First part
------------
Our log file showing the PROPFIND, PUT, and GET commands.
 
Second Part
----------------
The storelog.html file for the PROPFIND, PUT, and GET
 
Third Part
-------------
Our log file showing just a PROPFIND coming through after I updated the loc= ation and tried to sync
 
Fourth Part
---------------
The storelog.html file with the sync after I updated the location.
 
It seems like it does not recognize the fact that there was an update made = at the client side. If I delete the event and sync it does delete the event = on the server. Let me know if you need any other logs.
 
thanks,
Shad



 

 


 --B_3257253069_37133-- From groupdav@opengroupware.org Wed Mar 21 22:47:12 2007 From: groupdav@opengroupware.org (Tews, Shad) Date: Wed, 21 Mar 2007 16:47:12 -0600 Subject: [GroupDAV] Question about the Strategy Configuration References: Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C76C0A.DDA15CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the funambol admin tool on the Strategy Panel under conflict = resolution there is a Client wins and a Server wins option. When looking = at the code in vCalGroupDAVConnector it appears that if it is set to = "Server Wins" there will never be any updates propigated from the client = to the server. In there it appears that this setting is being looked at = incorrectly. My understanding of this setting is that it is used only if = there has been changes to an event or contact on both the client and the = server and there has to be a decision made as to whose data is correct. = I wouldn't expect this option to be used unless that condition had been = detected. Do you ever attempt to detect this condition? Or does this = responsibility lie within the Funambol code? =20 Also, do you happen to have a server we can test against? We would like = to have multiple locations that we can test against to try and detect if = we have incorrectly setup anything on our side. =20 thanks, Shad ------_=_NextPart_001_01C76C0A.DDA15CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [GroupDAV] Having problems with basic = functionality - Question of setup=0A= =0A= =0A= =0A=
=0A=
In the funambol admin tool on the Strategy Panel under = conflict resolution there is a Client wins and a Server wins option. = When looking at the code in vCalGroupDAVConnector it appears that if it = is set to "Server Wins" there will never be any updates propigated from = the client to the server. In there it appears that this setting is = being looked at incorrectly. My understanding of this setting is that it = is used only if there has been changes to an event or contact on = both the client and the server and there has to be a = decision made as to whose data is correct. I wouldn't expect this option = to be used unless that condition had been detected. Do you ever attempt = to detect this condition? Or does this responsibility lie within the = Funambol code?
=0A=
 
=0A=
Also, do you happen to have a server we can test against? = We would like to have multiple locations that we can test against to try = and detect if we have incorrectly setup anything on our side.
=0A=
 
=0A=
thanks,
=0A=
Shad


 

 

------_=_NextPart_001_01C76C0A.DDA15CE0-- From groupdav@opengroupware.org Thu Mar 22 03:46:17 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Thu, 22 Mar 2007 14:46:17 +1100 Subject: [GroupDAV] Question about the Strategy Configuration In-Reply-To: Message-ID: The event sync source shouldn=B9t need to do any special processing depending on the set strategy (client/server wins), as Funambol handles this itself. The strategy is provided to us at the start of sync but theres no need to check it, however there are places in the GroupDAV sync sources where its been checked to ensure sanity, they=B9ll vanish when I get around to removing them. Don't confuse that with the synchronization mode (slow,normal,from server only, to client only) which is checked in getAllSyncItemKeys() I currently don't have any servers with the connector on it available for external use.=20 On 22/3/07 9:47 AM, "Tews, Shad" wrote: > In the funambol admin tool on the Strategy Panel under conflict resolutio= n > there is a Client wins and a Server wins option. When looking at the code= in > vCalGroupDAVConnector it appears that if it is set to "Server Wins" there= will > never be any updates propigated from the client to the server. In there i= t > appears that this setting is being looked at incorrectly. My understandin= g of > this setting is that it is used only if there has been changes to an even= t or > contact on both the client and the server and there has to be a decision = made > as to whose data is correct. I wouldn't expect this option to be used unl= ess > that condition had been detected. Do you ever attempt to detect this > condition? Or does this responsibility lie within the Funambol code? > =20 > Also, do you happen to have a server we can test against? We would like t= o > have multiple locations that we can test against to try and detect if we = have > incorrectly setup anything on our side. > =20 > thanks, > Shad >=20 >=20 >=20 > =20 >=20 > =20 >=20 From groupdav@opengroupware.org Thu Mar 22 05:39:07 2007 From: groupdav@opengroupware.org (Tews, Shad) Date: Wed, 21 Mar 2007 23:39:07 -0600 Subject: [GroupDAV] Question about the Strategy Configuration References: Message-ID: This is a multi-part message in MIME format. ------_=_NextPart_001_01C76C44.68959FE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Correct me if I am wrong but currently if the setting is "Server Wins" = then there is no way any updates made on the client will happen at the = server, which to me seems incorrect. This setting should only come into = play if there are changes made to both the cleitn and server prior to = sync'ing. =20 thanks, Shad ________________________________ From: groupdav-admin@opengroupware.org on behalf of Mathew McBride Sent: Wed 3/21/2007 9:46 PM To: groupdav@opengroupware.org Subject: Re: [GroupDAV] Question about the Strategy Configuration The event sync source shouldn=B9t need to do any special processing = depending on the set strategy (client/server wins), as Funambol handles this = itself. The strategy is provided to us at the start of sync but theres no need = to check it, however there are places in the GroupDAV sync sources where = its been checked to ensure sanity, they=B9ll vanish when I get around to = removing them. Don't confuse that with the synchronization mode (slow,normal,from = server only, to client only) which is checked in getAllSyncItemKeys() I currently don't have any servers with the connector on it available = for external use. On 22/3/07 9:47 AM, "Tews, Shad" wrote: > In the funambol admin tool on the Strategy Panel under conflict = resolution > there is a Client wins and a Server wins option. When looking at the = code in > vCalGroupDAVConnector it appears that if it is set to "Server Wins" = there will > never be any updates propigated from the client to the server. In = there it > appears that this setting is being looked at incorrectly. My = understanding of > this setting is that it is used only if there has been changes to an = event or > contact on both the client and the server and there has to be a = decision made > as to whose data is correct. I wouldn't expect this option to be used = unless > that condition had been detected. Do you ever attempt to detect this > condition? Or does this responsibility lie within the Funambol code? >=20 > Also, do you happen to have a server we can test against? We would = like to > have multiple locations that we can test against to try and detect if = we have > incorrectly setup anything on our side. >=20 > thanks, > Shad > > > >=20 > >=20 > -- GroupDAV groupdav@opengroupware.org http://mail.opengroupware.org/mailman/listinfo/groupdav ------_=_NextPart_001_01C76C44.68959FE4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [GroupDAV] Question about the Strategy = Configuration=0A= =0A= =0A= =0A=
=0A=
Correct me if = I am wrong but currently if the setting is "Server Wins" then there is = no way any updates made on the client will happen at the server, which = to me seems incorrect. This setting should only come into play if there = are changes made to both the cleitn and server prior to = sync'ing.
=0A=
 
=0A=
thanks,
=0A=
Shad
=0A=

=0A=
=0A= From: = groupdav-admin@opengroupware.org on behalf of Mathew = McBride
Sent: Wed 3/21/2007 9:46 PM
To: = groupdav@opengroupware.org
Subject: Re: [GroupDAV] Question = about the Strategy Configuration

=0A=
=0A=

The event sync source shouldn=B9t need to do any = special processing depending
on the set strategy (client/server = wins), as Funambol handles this itself.

The strategy is provided = to us at the start of sync but theres no need to
check it, however = there are places in the GroupDAV sync sources where its
been checked = to ensure sanity, they=B9ll vanish when I get around to = removing
them.

Don't confuse that with the synchronization = mode (slow,normal,from server
only, to client only) which is checked = in getAllSyncItemKeys()

I currently don't have any servers with = the connector on it available for
external use.

On 22/3/07 = 9:47 AM, "Tews, Shad" <Shad.Tews@corpx.usa.net> wrote:

> = In the funambol admin tool on the Strategy Panel under conflict = resolution
> there is a Client wins and a Server wins option. When = looking at the code in
> vCalGroupDAVConnector it appears that if = it is set to "Server Wins" there will
> never be any updates = propigated from the client to the server. In there it
> appears = that this setting is being looked at incorrectly. My understanding = of
> this setting is that it is used only if there has been = changes to an event or
> contact on both the client and the server = and there has to be a decision made
> as to whose data is correct. = I wouldn't expect this option to be used unless
> that condition = had been detected. Do you ever attempt to detect this
> condition? = Or does this responsibility lie within the Funambol = code?
> 
> Also, do you happen to have a server we can = test against? We would like to
> have multiple locations that we = can test against to try and detect if we have
> incorrectly setup = anything on our side.
> 
> thanks,
> = Shad
>
>
>
> 
>
> 
><= BR>

--
GroupDAV
groupdav@opengroupware.org
http://m= ail.opengroupware.org/mailman/listinfo/groupdav




 

 

------_=_NextPart_001_01C76C44.68959FE4-- From groupdav@opengroupware.org Thu Mar 22 05:47:48 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Thu, 22 Mar 2007 16:47:48 +1100 Subject: [GroupDAV] Question about the Strategy Configuration In-Reply-To: Message-ID: In the case of updateSyncItem, yes, the check shouldn=B9t be there, and It=B9ll be gone in the next release. On 22/3/07 4:39 PM, "Tews, Shad" wrote: > Correct me if I am wrong but currently if the setting is "Server Wins" th= en > there is no way any updates made on the client will happen at the server, > which to me seems incorrect. This setting should only come into play if t= here > are changes made to both the cleitn and server prior to sync'ing. > =20 > thanks, > Shad >=20 >=20 > From: groupdav-admin@opengroupware.org on behalf of Mathew McBride > Sent: Wed 3/21/2007 9:46 PM > To: groupdav@opengroupware.org > Subject: Re: [GroupDAV] Question about the Strategy Configuration >=20 > The event sync source shouldn=B9t need to do any special processing dependi= ng > on the set strategy (client/server wins), as Funambol handles this itself= From groupdav@opengroupware.org Fri Mar 30 23:27:09 2007 From: groupdav@opengroupware.org (groupdav@opengroupware.org) Date: Fri, 30 Mar 2007 18:27:09 -0400 Subject: [GroupDAV] =?utf-8?Q?announcing=20SOGo=20=28Inverse=20edition=29?= Message-ID: Hello everyone! After many months of development, we happy to publicize a little more our work. We, at Inverse, have been working actively in the past few months on Scalable Opengroupware.org (SOGo) and we created related projects around it. Here's what we've accomplished on various projects: [ Scalable OpenGroupware.org ] Based on the excellent work that already existed, we created an "Inverse" branch for the project. Our goal is to mimic the look and the functionality of the Mozilla application suite (Thunderbird / Lightning / Sunbird) in order to have a perfect integration between both. In pursuing that goal, we contributed to the project by adding, among many other things: - Fresh user interface based on AJAX which mimic Thunderbird / Lighthing / Sunbird look - Calendar and address book sharing capabilities using WebDAV ACLs - Tasks support and vCard storage support for contacts - Multiple address books and LDAP-based address books - CalDAV support We still actively work on the project and much more is to come very soon! [ Thunderbird Address Book GroupDAV Connector ] Synchronizing contacts with Thunderbird was also an important feature to have for SOGo. Thus, we created the Thunderbird Address Book GroupDAV Connector. It allows you to create any number of address books and synchronize them with any GroupDAV-based server. The plugin not only supports SOGo, but also OpenGroupware.org (OGo) and Citadel. [ Mozilla Thunderbird / Lightning ] Perfect integration with Mozilla Thunderbird and Lighthing is also one of our goals. In order to acheive that, we created a small extension for Lighthing so it better integrates with SOGo (but in fact, with any standards-compliant groupware servers). While all the calendaring part is handled by the CalDAV provider, this extension allows us to have Free/Busy support from Lightning and very soon, basic preferences sharing. You can learn more about those projects by visiting our website at http://inverse.ca The website also contains plenty of screenshots of all projects. We also completed many pilot projects with the solution and all its components. Feedback and comments are more than welcome. You can do so by sending a mail either to this list or to support@inverse.ca -- OpenGroupware.org Developer developer@opengroupware.org http://mail.opengroupware.org/mailman/listinfo/developer