GroupDAV Limit 500 Einträge?

[moe]

Hallo,

in der 14.2 scheint es eine Limitierung zu geben was die Anzahl der
Einträge zum Abgleichen angeht. Eine Externe Firma, die eine Anwendung
für uns entwickelt hat synct aktuell mit der 1.8.007 ohne Probleme.
Bei Test mit der 14.2 wurde mir mitgeteilt, dass max 499 Einträge
abgeglichen
werden können.
Dazu schrieb mir der Entwickler:
------------schnipp----------------
In der Datei „addressbook/class.addressbook_groupdav.inc.php“ befindet
sich eine Funktion namens „&propfind_callback“. Wird dort der Parameter
„report_not_found_multiget_ids“ auf „false“ statt „true“ gesetzt, ließen
sich auch mehr als 500 Vcards abfragen. Falls ich mich nicht täusche
wurde diese Änderung in der Rev. 43891 der Datei implementiert.

Auch wenn es sich um eine gewollte Limitierung handeln sollte, ist es
doch zumindest merkwürdig, dass ich eine schier endlose Liste von
Einträgen in der Nachfolgenden Form vom Server erhalte, vielleicht hilft
dies zur Fehlerbehebung:

<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/groupdav.php/addressbook/edf31a15-568f-4dd9-92a9-9791a13d4cb9.vcf</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:response>

Es handelt sich dabei wohlgemerkt um eine Vcard die innerhalb der
gleichen Rückgabe zuvor erfolgreich zurückgegeben wurde.
------------schnapp----------------

Ist das so gewollt? Mit welchem Hintergrund?
Wie kann man das sauber lösen?

Moe

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

[Ralf_Becker_Stylite]

Hi Moe,

die Frage ist wie werden die Kontakte abgefragt:
a) Propfind mit addressbook-data
b) Multiget Report
c) Sync-Collection Report

Die Änderung kommt aus der Implementation des Sync-Collection Reports.
Den Default Parameter einfach zu ändern macht den Report kaputt und wird
sicher dazu führen, dass Clients die den Verwenden nicht mehr richtig
synchronisieren.

Das einfachste ist mal das Logging zu aktivieren. Dann sieht man genau
was Euer Client macht und wo es schief geht.

Ralf

Hallo,

in der 14.2 scheint es eine Limitierung zu geben was die Anzahl der
Einträge zum Abgleichen angeht. Eine Externe Firma, die eine Anwendung
für uns entwickelt hat synct aktuell mit der 1.8.007 ohne Probleme.
Bei Test mit der 14.2 wurde mir mitgeteilt, dass max 499 Einträge
abgeglichen
werden können.
Dazu schrieb mir der Entwickler:
------------schnipp----------------
In der Datei „addressbook/class.addressbook_groupdav.inc.php“ befindet
sich eine Funktion namens „&propfind_callback“. Wird dort der Parameter
„report_not_found_multiget_ids“ auf „false“ statt „true“ gesetzt, ließen
sich auch mehr als 500 Vcards abfragen. Falls ich mich nicht täusche
wurde diese Änderung in der Rev. 43891 der Datei implementiert.

Auch wenn es sich um eine gewollte Limitierung handeln sollte, ist es
doch zumindest merkwürdig, dass ich eine schier endlose Liste von
Einträgen in der Nachfolgenden Form vom Server erhalte, vielleicht hilft
dies zur Fehlerbehebung:

<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/groupdav.php/addressbook/edf31a15-568f-4dd9-92a9-9791a13d4cb9.vcf</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:response>

Es handelt sich dabei wohlgemerkt um eine Vcard die innerhalb der
gleichen Rückgabe zuvor erfolgreich zurückgegeben wurde.
------------schnapp----------------

Ist das so gewollt? Mit welchem Hintergrund?
Wie kann man das sauber lösen?

Moe

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

–
Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

[moe]

Hallo Ralf,

vielen Dank für Deine Antwort.
Die Antwort der Entwickler darauf lautet:

----------schnipp-----------------

Zur Abfrage der Kontakte wird ein “Multiget Report” verwendet.

Konkret sieht der gestellt Request wie folgt aus:

<?xml version="1.0" encoding="utf-8" ?>

<C:addressbook-multiget
xmlns:D="DAV:"xmlns:C=“urn:ietf:params:xml:ns:carddav”>

<D:prop>

<D:getetag/>

<D:getlastmodified/>

<C:address-data>

<D:allprop/>

</C:address-data>

</D:prop>

<D:href> /groupdav.php/addressbook/1.vcf </D:href>

<D:href> /groupdav.php/addressbook/2.vcf </D:href>

<D:href>
/groupdav.php/addressbook/ce1443d9-a070-41e7-90b9-0ddf25511111.vcf </D:href>

(… etc. für die weiteren Links)

</C:addressbook-multiget>

Dies funktionierte wie gesagt vor der Version 14.x reibungslos. Werden
ab Version 14.x nun mehr als 499 VCards angefragt erhalte ich den
folgenden von mir gekürzten Response:

<?xml version="1.0" encoding="utf-8"?>

<D:multistatus xmlns:D=“DAV:”>

<D:response xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
xmlns:ns2=“urn:ietf:params:xml:ns:carddav”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

<D:propstat>

<D:prop>

<D:getlastmodified ns0:dt=“dateTime.rfc1123”>Mon, 17 Mar 2014 07:46:40
GMT</D:getlastmodified>

ns2:address-data<![CDATA[BEGIN:VCARD

VERSION:3.0

PRODID:-//EGroupware//NONSGML EGroupware Addressbook 14.2//DE

ADR;TYPE=WORK:;;Straße 1;Berlin;;133333;DEUTSCHLAND

CLASS:PUBLIC

EMAIL;TYPE=WORK:test@test.de

N:NACHNAME;VORNAME;;Frau;

FN:Frau VORNAME NACHNAME

NOTE: Notiz Text.

ORG:;;

TEL;TYPE=CELL,WORK:0049 (0)175 - 111 11 11

TEL;TYPE=VOICE,WORK:0049 (0)30 - 111 11 12

TEL;TYPE=FAX,WORK:0049 (0) 30 - 111 11 13

UID:addressbook-3-25267f01a5728dc39e4aa4bcb9f64cad

REV:2014-03-17T07:46:40Z

END:VCARD

]]></ns2:address-data>

<D:getetag>“3:0”</D:getetag>

</D:prop>

<D:status>HTTP/1.1 200 OK</D:status>

</D:propstat>

</D:response>

(… Es folgt eine Reihe weiterer VCards. Anschließend übermittelt der
Server ununterbrochen für eine Gruppe von sich immer wiederholenden
Vcards die

Nachfolgenden Daten)

<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

<D:status>HTTP/1.1 404 Not Found</D:status>

</D:response>

Dabei ist mir gerade dies auch unklar, da die in diesem Beispiel
aufgeführte VCard bereits zuvor gefunden wurde. Zumindest würde ich
erwarten, dass der Server die Nachricht nach 499 Vcards sauber abbricht,
da auch dies nicht geschieht gehe ich von einem Fehler aus. Muss
womöglich ab Version 14.x der Request anders formuliert werden (wovon
ich nicht ausgehe)?

--------schnapp---------------

Kann es sein, dass der Request anders formuliert werden muss?

Moe

[moe]

Hallo Ralf,

hast Du noch einen Hinweis diesbzgl.?

Gruß Moe

[Ralf_Becker_Stylite]

Hi Moe,

ich denke mal das ist ein Fehler bei uns, der im Zuge des
Sync-Collection-Reports rein kam.
Bin noch nicht dazu gekommen mir das anzuschauen.

Allerdings ist es auch sehr ungeschickt einen so großen Multiget Report
zu senden.

Die meisten Clients machen entsprechend viele Multiget Reports mit
50-100 Kontakten.
Ansonsten stößt Du halt auch sehr leicht an diverse Server-Limits
(max_excution_time, memory_limit, …).

Ralf

Hallo Ralf,

hast Du noch einen Hinweis diesbzgl.?

Gruß Moe

Hallo Ralf,

vielen Dank für Deine Antwort.
Die Antwort der Entwickler darauf lautet:

----------schnipp-----------------

Zur Abfrage der Kontakte wird ein „Multiget Report“ verwendet.

Konkret sieht der gestellt Request wie folgt aus:

<?xml version="1.0" encoding="utf-8" ?>

<C:addressbook-multiget
xmlns:D="DAV:"xmlns:C=“urn:ietf:params:xml:ns:carddav”>

            <D:prop>

                           <D:getetag/>

                           <D:getlastmodified/>

                           <C:address-data>

                                           <D:allprop/>

                           </C:address-data>

            </D:prop>

            <D:href> /groupdav.php/addressbook/1.vcf </D:href>

            <D:href> /groupdav.php/addressbook/2.vcf </D:href>

            <D:href>

/groupdav.php/addressbook/ce1443d9-a070-41e7-90b9-0ddf25511111.vcf
</D:href>

            (... etc. für die weiteren Links)

</C:addressbook-multiget>

Dies funktionierte wie gesagt vor der Version 14.x reibungslos.
Werden ab Version 14.x nun mehr als 499 VCards angefragt erhalte ich
den folgenden von mir gekürzten Response:

<?xml version="1.0" encoding="utf-8"?>

<D:multistatus xmlns:D=“DAV:”>

            <D:response

xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
xmlns:ns2=“urn:ietf:params:xml:ns:carddav”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

               <D:propstat>

                           <D:prop>

                           <D:getlastmodified

ns0:dt=“dateTime.rfc1123”>Mon, 17 Mar 2014 07:46:40
GMT</D:getlastmodified>

                           <ns2:address-data><![CDATA[BEGIN:VCARD

            VERSION:3.0

            PRODID:-//EGroupware//NONSGML EGroupware Addressbook

14.2//DE

            ADR;TYPE=WORK:;;Straße 1;Berlin;;133333;DEUTSCHLAND

            CLASS:PUBLIC

            EMAIL;TYPE=WORK:test@test.de

            N:NACHNAME;VORNAME;;Frau;

            FN:Frau VORNAME NACHNAME

            NOTE: Notiz Text.

            ORG:;;

            TEL;TYPE=CELL,WORK:0049 (0)175 - 111 11 11

            TEL;TYPE=VOICE,WORK:0049 (0)30 - 111 11 12

            TEL;TYPE=FAX,WORK:0049 (0) 30 - 111 11 13

            UID:addressbook-3-25267f01a5728dc39e4aa4bcb9f64cad

            REV:2014-03-17T07:46:40Z

            END:VCARD

            ]]></ns2:address-data>

                           <D:getetag>"3:0"</D:getetag>

                           </D:prop>

               <D:status>HTTP/1.1 200 OK</D:status>

              </D:propstat>

            </D:response>

             (... Es folgt eine Reihe weiterer VCards.

Anschließend übermittelt der Server ununterbrochen für eine Gruppe
von sich immer wiederholenden Vcards die

Nachfolgenden Daten)

            <D:response

xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

                           <D:status>HTTP/1.1 404 Not

Found</D:status>

            </D:response>

Dabei ist mir gerade dies auch unklar, da die in diesem Beispiel
aufgeführte VCard bereits zuvor gefunden wurde. Zumindest würde ich
erwarten, dass der Server die Nachricht nach 499 Vcards sauber
abbricht, da auch dies nicht geschieht gehe ich von einem Fehler aus.
Muss womöglich ab Version 14.x der Request anders formuliert werden
(wovon ich nicht ausgehe)?

--------schnapp---------------

Kann es sein, dass der Request anders formuliert werden muss?

Moe

Hi Moe,

die Frage ist wie werden die Kontakte abgefragt:
a) Propfind mit addressbook-data
b) Multiget Report
c) Sync-Collection Report

Die Änderung kommt aus der Implementation des Sync-Collection Reports.
Den Default Parameter einfach zu ändern macht den Report kaputt und wird
sicher dazu führen, dass Clients die den Verwenden nicht mehr richtig
synchronisieren.

Das einfachste ist mal das Logging zu aktivieren. Dann sieht man genau
was Euer Client macht und wo es schief geht.

Ralf

Hallo,

in der 14.2 scheint es eine Limitierung zu geben was die Anzahl der
Einträge zum Abgleichen angeht. Eine Externe Firma, die eine Anwendung
für uns entwickelt hat synct aktuell mit der 1.8.007 ohne Probleme.
Bei Test mit der 14.2 wurde mir mitgeteilt, dass max 499 Einträge
abgeglichen
werden können.
Dazu schrieb mir der Entwickler:
------------schnipp----------------
In der Datei „addressbook/class.addressbook_groupdav.inc.php“ befindet
sich eine Funktion namens „&propfind_callback“. Wird dort der Parameter
„report_not_found_multiget_ids“ auf „false“ statt „true“ gesetzt, ließen
sich auch mehr als 500 Vcards abfragen. Falls ich mich nicht täusche
wurde diese Änderung in der Rev. 43891 der Datei implementiert.

Auch wenn es sich um eine gewollte Limitierung handeln sollte, ist es
doch zumindest merkwürdig, dass ich eine schier endlose Liste von
Einträgen in der Nachfolgenden Form vom Server erhalte, vielleicht hilft
dies zur Fehlerbehebung:

<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/groupdav.php/addressbook/edf31a15-568f-4dd9-92a9-9791a13d4cb9.vcf</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:response>

Es handelt sich dabei wohlgemerkt um eine Vcard die innerhalb der
gleichen Rückgabe zuvor erfolgreich zurückgegeben wurde.
------------schnapp----------------

Ist das so gewollt? Mit welchem Hintergrund?
Wie kann man das sauber lösen?

Moe

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

This body part will be downloaded on demand.

This body part will be downloaded on demand.

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

–
Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

[moe]

Hi Ralf,

vielen Dank für die Info!
Ich werde die Entwickler bitten vorerst die Änderung auf 50-100 Kontakte
vorzunehmen.
Den Bugreport gibt es ja schon dazu.

Gruß Moe

[Ralf_Becker_Stylite]

Hi Moe,

ist jetzt behoben:

http://svn.stylite.de/viewvc/egroupware?revision=52505&view=revision

Bitte mal kurz Feedback geben, ob es damit bei Dir funktioniert.

Ralf

Hi Ralf,

vielen Dank für die Info!
Ich werde die Entwickler bitten vorerst die Änderung auf 50-100
Kontakte vorzunehmen.
Den Bugreport gibt es ja schon dazu.

Gruß Moe

Hi Moe,

ich denke mal das ist ein Fehler bei uns, der im Zuge des
Sync-Collection-Reports rein kam.
Bin noch nicht dazu gekommen mir das anzuschauen.

Allerdings ist es auch sehr ungeschickt einen so großen Multiget Report
zu senden.

Die meisten Clients machen entsprechend viele Multiget Reports mit
50-100 Kontakten.
Ansonsten stößt Du halt auch sehr leicht an diverse Server-Limits
(max_excution_time, memory_limit, …).

Ralf

Hallo Ralf,

hast Du noch einen Hinweis diesbzgl.?

Gruß Moe

Hallo Ralf,

vielen Dank für Deine Antwort.
Die Antwort der Entwickler darauf lautet:

----------schnipp-----------------

Zur Abfrage der Kontakte wird ein „Multiget Report“ verwendet.

Konkret sieht der gestellt Request wie folgt aus:

<?xml version="1.0" encoding="utf-8" ?>

<C:addressbook-multiget
xmlns:D="DAV:"xmlns:C=“urn:ietf:params:xml:ns:carddav”>

            <D:prop>

                           <D:getetag/>

                           <D:getlastmodified/>

                           <C:address-data>

                                           <D:allprop/>

                           </C:address-data>

            </D:prop>

            <D:href> /groupdav.php/addressbook/1.vcf </D:href>

            <D:href> /groupdav.php/addressbook/2.vcf </D:href>

            <D:href>

/groupdav.php/addressbook/ce1443d9-a070-41e7-90b9-0ddf25511111.vcf
</D:href>

            (... etc. für die weiteren Links)

</C:addressbook-multiget>

Dies funktionierte wie gesagt vor der Version 14.x reibungslos.
Werden ab Version 14.x nun mehr als 499 VCards angefragt erhalte ich
den folgenden von mir gekürzten Response:

<?xml version="1.0" encoding="utf-8"?>

<D:multistatus xmlns:D=“DAV:”>

            <D:response

xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
xmlns:ns2=“urn:ietf:params:xml:ns:carddav”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

               <D:propstat>

                           <D:prop>

                           <D:getlastmodified

ns0:dt=“dateTime.rfc1123”>Mon, 17 Mar 2014 07:46:40
GMT</D:getlastmodified>

                           <ns2:address-data><![CDATA[BEGIN:VCARD

            VERSION:3.0

            PRODID:-//EGroupware//NONSGML EGroupware Addressbook

14.2//DE

            ADR;TYPE=WORK:;;Straße 1;Berlin;;133333;DEUTSCHLAND

            CLASS:PUBLIC

            EMAIL;TYPE=WORK:test@test.de

            N:NACHNAME;VORNAME;;Frau;

            FN:Frau VORNAME NACHNAME

            NOTE: Notiz Text.

            ORG:;;

            TEL;TYPE=CELL,WORK:0049 (0)175 - 111 11 11

            TEL;TYPE=VOICE,WORK:0049 (0)30 - 111 11 12

            TEL;TYPE=FAX,WORK:0049 (0) 30 - 111 11 13

            UID:addressbook-3-25267f01a5728dc39e4aa4bcb9f64cad

            REV:2014-03-17T07:46:40Z

            END:VCARD

            ]]></ns2:address-data>

                           <D:getetag>"3:0"</D:getetag>

                           </D:prop>

               <D:status>HTTP/1.1 200 OK</D:status>

              </D:propstat>

            </D:response>

             (... Es folgt eine Reihe weiterer VCards.

Anschließend übermittelt der Server ununterbrochen für eine Gruppe
von sich immer wiederholenden Vcards die

Nachfolgenden Daten)

            <D:response

xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

                           <D:status>HTTP/1.1 404 Not

Found</D:status>

            </D:response>

Dabei ist mir gerade dies auch unklar, da die in diesem Beispiel
aufgeführte VCard bereits zuvor gefunden wurde. Zumindest würde ich
erwarten, dass der Server die Nachricht nach 499 Vcards sauber
abbricht, da auch dies nicht geschieht gehe ich von einem Fehler aus.
Muss womöglich ab Version 14.x der Request anders formuliert werden
(wovon ich nicht ausgehe)?

--------schnapp---------------

Kann es sein, dass der Request anders formuliert werden muss?

Moe

Hi Moe,

die Frage ist wie werden die Kontakte abgefragt:
a) Propfind mit addressbook-data
b) Multiget Report
c) Sync-Collection Report

Die Änderung kommt aus der Implementation des Sync-Collection Reports.
Den Default Parameter einfach zu ändern macht den Report kaputt und wird
sicher dazu führen, dass Clients die den Verwenden nicht mehr richtig
synchronisieren.

Das einfachste ist mal das Logging zu aktivieren. Dann sieht man genau
was Euer Client macht und wo es schief geht.

Ralf

Hallo,

in der 14.2 scheint es eine Limitierung zu geben was die Anzahl der
Einträge zum Abgleichen angeht. Eine Externe Firma, die eine Anwendung
für uns entwickelt hat synct aktuell mit der 1.8.007 ohne Probleme.
Bei Test mit der 14.2 wurde mir mitgeteilt, dass max 499 Einträge
abgeglichen
werden können.
Dazu schrieb mir der Entwickler:
------------schnipp----------------
In der Datei „addressbook/class.addressbook_groupdav.inc.php“ befindet
sich eine Funktion namens „&propfind_callback“. Wird dort der Parameter
„report_not_found_multiget_ids“ auf „false“ statt „true“ gesetzt, ließen
sich auch mehr als 500 Vcards abfragen. Falls ich mich nicht täusche
wurde diese Änderung in der Rev. 43891 der Datei implementiert.

Auch wenn es sich um eine gewollte Limitierung handeln sollte, ist es
doch zumindest merkwürdig, dass ich eine schier endlose Liste von
Einträgen in der Nachfolgenden Form vom Server erhalte, vielleicht hilft
dies zur Fehlerbehebung:

<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/groupdav.php/addressbook/edf31a15-568f-4dd9-92a9-9791a13d4cb9.vcf</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:response>

Es handelt sich dabei wohlgemerkt um eine Vcard die innerhalb der
gleichen Rückgabe zuvor erfolgreich zurückgegeben wurde.
------------schnapp----------------

Ist das so gewollt? Mit welchem Hintergrund?
Wie kann man das sauber lösen?

Moe

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

This body part will be downloaded on demand.

This body part will be downloaded on demand.

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

–
Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

[moe]

Hallo Ralf,

vielen Dank!

Ich habe die Infos gleich weiter gegeben und folgende Antowrt erhalten:

---

ich habe die von Ihnen spezifizierte Datei in meiner Egroupware
Installation ausgetauscht. Leider verschlimmerte dies die Situation, da
dadurch ein zuvor stattfindender Request bereist schiefgeht (ein
propfind request mit dem ich die VCard Urls und Etags Abfrage). Ich
erhalte nun lediglich einen Response mit dem Pfad zum Addressbuch, nicht
jedoch die Informationen zu den VCards. Ich kann dies gerade zeitlich
leider nicht eingehender untersuchen.

---

Ich hoffe das hilft bei debuggen?!?

Moe

[Ralf_Becker_Stylite]

Hi Moe,

ist jetzt auch behoben mit:

https://svn.stylite.de/viewvc/egroupware?revision=52547&view=revision

Ralf

Hallo Ralf,

vielen Dank!

Ich habe die Infos gleich weiter gegeben und folgende Antowrt erhalten:

---

ich habe die von Ihnen spezifizierte Datei in meiner Egroupware
Installation ausgetauscht. Leider verschlimmerte dies die Situation,
da dadurch ein zuvor stattfindender Request bereist schiefgeht (ein
propfind request mit dem ich die VCard Urls und Etags Abfrage). Ich
erhalte nun lediglich einen Response mit dem Pfad zum Addressbuch,
nicht jedoch die Informationen zu den VCards. Ich kann dies gerade
zeitlich leider nicht eingehender untersuchen.

---

Ich hoffe das hilft bei debuggen?!?

Moe

Hi Moe,

ist jetzt behoben:

http://svn.stylite.de/viewvc/egroupware?revision=52505&view=revision

Bitte mal kurz Feedback geben, ob es damit bei Dir funktioniert.

Ralf

Hi Ralf,

vielen Dank für die Info!
Ich werde die Entwickler bitten vorerst die Änderung auf 50-100
Kontakte vorzunehmen.
Den Bugreport gibt es ja schon dazu.

Gruß Moe

Hi Moe,

ich denke mal das ist ein Fehler bei uns, der im Zuge des
Sync-Collection-Reports rein kam.
Bin noch nicht dazu gekommen mir das anzuschauen.

Allerdings ist es auch sehr ungeschickt einen so großen Multiget Report
zu senden.

Die meisten Clients machen entsprechend viele Multiget Reports mit
50-100 Kontakten.
Ansonsten stößt Du halt auch sehr leicht an diverse Server-Limits
(max_excution_time, memory_limit, …).

Ralf

Hallo Ralf,

hast Du noch einen Hinweis diesbzgl.?

Gruß Moe

Hallo Ralf,

vielen Dank für Deine Antwort.
Die Antwort der Entwickler darauf lautet:

----------schnipp-----------------

Zur Abfrage der Kontakte wird ein „Multiget Report“ verwendet.

Konkret sieht der gestellt Request wie folgt aus:

<?xml version="1.0" encoding="utf-8" ?>

<C:addressbook-multiget
xmlns:D="DAV:"xmlns:C=“urn:ietf:params:xml:ns:carddav”>

            <D:prop>

                           <D:getetag/>

                           <D:getlastmodified/>

                           <C:address-data>

                                           <D:allprop/>

                           </C:address-data>

            </D:prop>

            <D:href> /groupdav.php/addressbook/1.vcf </D:href>

            <D:href> /groupdav.php/addressbook/2.vcf </D:href>

            <D:href>

/groupdav.php/addressbook/ce1443d9-a070-41e7-90b9-0ddf25511111.vcf
</D:href>

            (... etc. für die weiteren Links)

</C:addressbook-multiget>

Dies funktionierte wie gesagt vor der Version 14.x reibungslos.
Werden ab Version 14.x nun mehr als 499 VCards angefragt erhalte ich
den folgenden von mir gekürzten Response:

<?xml version="1.0" encoding="utf-8"?>

<D:multistatus xmlns:D=“DAV:”>

            <D:response

xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"
xmlns:ns2=“urn:ietf:params:xml:ns:carddav”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

               <D:propstat>

                           <D:prop>

                           <D:getlastmodified

ns0:dt=“dateTime.rfc1123”>Mon, 17 Mar 2014 07:46:40
GMT</D:getlastmodified>

                           <ns2:address-data><![CDATA[BEGIN:VCARD

            VERSION:3.0

            PRODID:-//EGroupware//NONSGML EGroupware Addressbook

14.2//DE

            ADR;TYPE=WORK:;;Straße 1;Berlin;;133333;DEUTSCHLAND

            CLASS:PUBLIC

            EMAIL;TYPE=WORK:test@test.de

            N:NACHNAME;VORNAME;;Frau;

            FN:Frau VORNAME NACHNAME

            NOTE: Notiz Text.

            ORG:;;

            TEL;TYPE=CELL,WORK:0049 (0)175 - 111 11 11

            TEL;TYPE=VOICE,WORK:0049 (0)30 - 111 11 12

            TEL;TYPE=FAX,WORK:0049 (0) 30 - 111 11 13

            UID:addressbook-3-25267f01a5728dc39e4aa4bcb9f64cad

            REV:2014-03-17T07:46:40Z

            END:VCARD

            ]]></ns2:address-data>

                           <D:getetag>"3:0"</D:getetag>

                           </D:prop>

               <D:status>HTTP/1.1 200 OK</D:status>

              </D:propstat>

            </D:response>

             (... Es folgt eine Reihe weiterer VCards.

Anschließend übermittelt der Server ununterbrochen für eine Gruppe
von sich immer wiederholenden Vcards die

Nachfolgenden Daten)

            <D:response

xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>

<D:href>/groupdav.php/addressbook/ce1443d9-a070-45e7-98b9-0ddf25551ee9.vcf</D:href>

                           <D:status>HTTP/1.1 404 Not

Found</D:status>

            </D:response>

Dabei ist mir gerade dies auch unklar, da die in diesem Beispiel
aufgeführte VCard bereits zuvor gefunden wurde. Zumindest würde ich
erwarten, dass der Server die Nachricht nach 499 Vcards sauber
abbricht, da auch dies nicht geschieht gehe ich von einem Fehler aus.
Muss womöglich ab Version 14.x der Request anders formuliert werden
(wovon ich nicht ausgehe)?

--------schnapp---------------

Kann es sein, dass der Request anders formuliert werden muss?

Moe

Hi Moe,

die Frage ist wie werden die Kontakte abgefragt:
a) Propfind mit addressbook-data
b) Multiget Report
c) Sync-Collection Report

Die Änderung kommt aus der Implementation des Sync-Collection Reports.
Den Default Parameter einfach zu ändern macht den Report kaputt und wird
sicher dazu führen, dass Clients die den Verwenden nicht mehr richtig
synchronisieren.

Das einfachste ist mal das Logging zu aktivieren. Dann sieht man genau
was Euer Client macht und wo es schief geht.

Ralf

Hallo,

in der 14.2 scheint es eine Limitierung zu geben was die Anzahl der
Einträge zum Abgleichen angeht. Eine Externe Firma, die eine Anwendung
für uns entwickelt hat synct aktuell mit der 1.8.007 ohne Probleme.
Bei Test mit der 14.2 wurde mir mitgeteilt, dass max 499 Einträge
abgeglichen
werden können.
Dazu schrieb mir der Entwickler:
------------schnipp----------------
In der Datei „addressbook/class.addressbook_groupdav.inc.php“ befindet
sich eine Funktion namens „&propfind_callback“. Wird dort der Parameter
„report_not_found_multiget_ids“ auf „false“ statt „true“ gesetzt, ließen
sich auch mehr als 500 Vcards abfragen. Falls ich mich nicht täusche
wurde diese Änderung in der Rev. 43891 der Datei implementiert.

Auch wenn es sich um eine gewollte Limitierung handeln sollte, ist es
doch zumindest merkwürdig, dass ich eine schier endlose Liste von
Einträgen in der Nachfolgenden Form vom Server erhalte, vielleicht hilft
dies zur Fehlerbehebung:

<D:response xmlns:ns0=“urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/”>
<D:href>/groupdav.php/addressbook/edf31a15-568f-4dd9-92a9-9791a13d4cb9.vcf</D:href>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:response>

Es handelt sich dabei wohlgemerkt um eine Vcard die innerhalb der
gleichen Rückgabe zuvor erfolgreich zurückgegeben wurde.
------------schnapp----------------

Ist das so gewollt? Mit welchem Hintergrund?
Wie kann man das sauber lösen?

Moe

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german
This body part will be downloaded on demand.

This body part will be downloaded on demand.

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

–
Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

[moe]

Hallo Ralf,

vielen Dank! Nachdem nun die wichtigsten Probleme gelöst sind,
habe ich heute unseren Produktivserver auf die 14.2 umgestellt.

Weißt Du schon wann das nächste Paket released wird?
Ist ja schon wieder über 2 Wochen her

Gruß Moe

Hi Moe,

ist jetzt auch behoben mit:

 https://svn.stylite.de/viewvc/egroupware?revision=52547&view=revision

Ralf

---

BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

---

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german