On Wed, 2004-10-27 at 10:26 +0200, Daniel Florey wrote: > Hi, > This was quick!! While others (me) still think about how to start you already did it!
I figured I'd get the ball rolling so we could start discussing details :). ... snip ... > > - Property Promotion and Demotion > > http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#promotion > > Either using the extractor framework or the event framework (or both). The > > extractor > > framework probably won't allow for modifing the content on propatch. > > We should use the extractor framework and extend it if we cannot > achieve content modifications on property changes. This would be the > better approach than retrieving properties at runtime as they could > get indexed and a much faster search could be achieved. What I was thinking here as far as events are concerned was watching for PUT and PROPPATCH and modifying the content before it was stored. I don't know how this would effect indexing, though. I agree that extending the extractor framework is probably better. At the very least it should be easier to reuse than having to create a custom listener for each use case. Extractors will need to be able to: 1) Parse the contents of a file and set appropriate property values (it looks like this is done). 2) Parse proppatchs and modify the contents of the file. There needs to be sanity checking here to make sure the contents stay valid. 3) Same as 1, but be able to remove properties when they are removed from the file. > > > > - Calendaring REPORTs > > http://greenbytes.de/tech/webdav/draft-dusseault-caldav-02.html#reports > > > > - Administration App > > There are structural requirements in the spec ("Each Calendar MUST have a > > collection containing events") > > that will be a pain to maintain manually. There needs to be an application the > > wraps all the necessary > > webdav calls to create a calendar and setup the default permissions into a > > single command. > > > > As I promised long time ago to propose a new Slide API that will > consolidate the client and server API this might be a good starting > point. We need some methods in the CalDAV-part of the API that > reflects the most common needs. Would be a great benefit if we would > have the same methods available on client and server side (e.g. > createCalendarCollection(...) or something like that). This sounds like a really good idea to me :). Have you started a sketch anywhere of how this will look? -James --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
