Re: Evaluation

On Sat, 2009-05-16 at 13:35 +0200, Helge Hess wrote:
> On 15.05.2009, at 22:20, Adam Tauno Williams wrote:
> > Hrm,  it seems to be caught in a loop getting -
> > GET /zidestore/dbartley/public/Contacts/10121.vcf HTTP/1.  Which could
> > peg the CPU forever.  There is no reason it should retrieve an object
> > more than once.  Your response times look pretty good.
> > But it is odd that the request is answered with a 404 (Not Found) and
> > ZideOne tries again.  I wonder if the multistatus response [PROPFIND]
> > on /zidestore/dbartley/public/Contacts/ indicated that 10121.vcf was a
> > resource.
> Yes, as I said, the ZideStore is too old. It had quite a set of 

I believe his version has the GroupDAVv2 fixes from r2207.

The contents of the public/Contacts folder is initially derived from the
query -
SELECT c1.company_id AS pkey, c1.name AS sn, c1.firstname AS givenname,
c1.object_version AS version
FROM company c1
WHERE c1.is_person=1
AND (c1.is_account=0 OR c1.is_account IS NULL)
AND (c1.is_private=0 OR c1.is_private IS NULL);
[pg. 62 of the current WMOGAG, the "Folder Hierarchy" section covers how
each folder in ZideStore is derived from the database.]

I assume that 10121 is presented by this query?  Just curious why a
non-available contact is showing up.  Only think I can think of is that
it isn't getting filtered out by access-controls for the propfind but is
when you specifically try to retrieve it (?).

> GroupDAV related bugs. The trunk/OGo 1.2 ZideStore is good wrt WebDAV  
> support, but it really needs a lot of testing on which iCal/vCard  
> fields it properly decodes/encodes.

I started working on this a little while ago;  the recent editions of
WMOGAG have an Appendix of Logic commands including company::get-vcard
and company::set-vcard (starts on page 167 of the latest edition) that
covers, at least in part, the attribute mapping.

> Your analysis is correct. The PROPFIND returns 10121.vcf as a  
> resource, but then the GET fails with 404. This produces a loop (on  
> each sync check the plugin discovers the 'new' resource, only to  
> delete it locally during the 404-GET).


-- 
OpenGroupware.org Users
[email protected]
http://mail.opengroupware.org/mailman/listinfo/users