RE: REPORTS

> -----Original Message-----
> From: John Hall [mailto:johnhall@evergo.net] 
> Sent: Wednesday, September 05, 2001 4:48 PM
> To: 'Clemm, Geoff'; 'DeltaV'
> Subject: RE: REPORTS
> 
> 
> 
> Perhaps you could provide more explanation about why you 
> can't just invoke your PROPFIND code recursively on your 
> server to produce the expand-property report?
> 
> ======================================================
> 
> Current code propfind:
> Parse propfind.
> Get a list of directory entries.
> Print common top code for propfind.
> Itterate through list of entries, printing property values 
> found. Producing output that looks identical to a propfind response.
> 
> Current code version-history:
> Parse essentially identical to propfind.
> Cripple report to only deal with one item at a time, getting 
> one directory entry. Print common top code for propfind. For 
> entry, note flag that says "print all versions for this 
> file". Itterate through file versions, printing property 
> values found. Producing output that looks identical to a 
> propfind response.
> 
> 
> Projected code
> Rewrite parsing code entirely, trying to keep track of nested 
> conditional property lists. Get an initial list of directory 
> entries. Print common top code for propfind. Iterate through 
> list as before.
> 
> OOPS -- they asked for an extra special property that just 
> happens to be a list of hrefs.  (Hard code knowledge of type 
> of property here, and the fact that it requires extra special 
> processing).  Hmmm.  Hit the database again I guess, trying 
> to keep track of a separate list of directory entries along 
> with a separate list of property elements applied to those 
> directory entries, producing a different form of output (due 
> to nesting) than before.  (Hard code searches, probably, for 
> each supported DeltaV property that contains an href and is 
> supported / generated -- since the type of processing 
> necessary depends radically on what type of 'href' it is.  
> Rememeber to reset the property list of the object each and 
> every time you return from a call, since it could have changed.).  
> 
> Potential additional complications due to organization of database.
> 
> A bloody nightmare, actually.
> 
> ================================================
> 
> I don't regard this as a trivial change in the spec.  And I 
> thought we were in a period where we were making changes only 
> if no objection was raised in the interest of stabilizing the 
> draft and sending it out the door.
>

Received on Wednesday, 5 September 2001 19:48:47 UTC