Tickets :: Comment on [#3032] WebDAV / iCal support for Kronolith

* Your Email Address
* Spam protection	Enter the letters below: . .. .. ..___.___. \| \|\ /\|__\|[__ \| \|/\\| \/ \| \|\| \|
Comment	> Today I've made some new changes, which implement the first solution > I presented in my last comment. It adds in the file listings next to > the directory representing a calendar, also a file with the same > calendar name and the .ics extension. > > > > Currently it uses the exportCalendar api function which was already > created for ics.php. For PUT it uses a system where the > _kronolith_put function is called through the registry. This means > that other applications, such as turba, can also use a _turba_put > function in their api. > > > > The PUT function calles the import function in the api so the > calendar data is imported. I've chosen not to directly call the > input, mainly because it could work for kronolith, but I can imagine > that other applications cannot work with the import directly. This is > mainly because the totally different concepts that are used in the > import and put. PUT is based on a path with some file content, which > is radically different from importing a certain element in a > application. For this reason, I think the usage of an extra function > is legitimate. > > > > Although I use the import function directly now, I think it would be > nicer to use a seperate function for importing a iCalendar file in > total. This is because a PUT with a iCalendar file currently results > in the entire calendar being deleted and afterwards the elements from > the file are added again. This is because otherwise no elements can > be deleted (import only allows for adding). Another disadvantage is > that every entry is therefore seen as being modified on a PUT. A > better solution would be a seperate function that check for each > element if it has changed / added / deleted and modifies these > entries accordingly.
Attachment
Watch this ticket

Saved Queries