Inf-IT DAV Clients

davclients@lists.inf-it.com

314 discussions

Error: 'unable to save the event': unauthorized!
by Jim Seymour 17 May '13

17 May '13

Hi There, DAViCal 1.1.1 running, with several client types. Installed and got running CalDAVZap today. Browser is Firefox 21.0 on Linux Mint 13, using the Mate desktop. When I try to create an event in my calendar, I get "Error: 'unable to save the event': unauthorized!" Error Console tells me: Timestamp: 05/17/2013 04:54:35 PM Error: [Exception... "'Method not implemented' when calling method: [nsIAuthPrompt2::asyncPromptAuth]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

2 1

Multiple Calendars?
by Jim Seymour 17 May '13

17 May '13

Hi There, Have DAViCal server (1.1.1 with iOS patches applied) and several clients working with it. Trying CalDAVZap for a web-based solution. We have, of course, individual calendars. We'll have group calendars. (The biggest of which, in subscribers, will be the company-wide calendar.) We have individuals which will want to share calendars on a read-only basis with coworkers. Etc. I, for example, have my calendar, a resource (calendar) that is r/w by a DAViCal group, and a coworker's calendar is marked "public read." The only calendar that shows up is mine. Is it possible for CalDAVZap users to see the others? Write to the ones that should be writable by them? Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

2 1

Got Some CalDAVZap Questions
by Jim Seymour 17 May '13

17 May '13

Hi There, Before I ask questions that have already been asked & answered: Is there a mailing list archive somewhere? Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

3 2

Fwd: Re: [Tc-caldav-l] PROPPATCH on principal resources
by Ken Murchison 17 May '13

17 May '13

FYI. The message below is from some Apple folks that I know. One on the client side and one on the server side. I also received a response from one of the Oracle developers that their "server does not allow PROPPATCH on principal resources either. Calendar home or calendar collection are fine." -------- Original Message -------- Subject: Re: [Tc-caldav-l] PROPPATCH on principal resources Date: Wed, 15 May 2013 14:16:13 -0400 From: Cyrus Daboo <cyrus(a)daboo.name> To: Helge Heß <helge_hess(a)apple.com>, tc-caldav-l Reflector tc-caldav-l <tc-caldav-l(a)calconnect.org> Hi Helge, --On May 15, 2013 at 10:39:31 AM -0700 Helge Heß <helge_hess(a)apple.com> wrote: > I don't think it's a good idea even if some servers allow that (I mean > it's a good idea in pure DAV theory, but it's not a good choice in > practice ;-). Principals will be often mapped to some kind of > authentication service (say LDAP) and such rarely provide arbitrary extra > storage. > > My guess is that PROPPATCHing something into the home is probably going > to work slightly better. But it's still not required and I would expect > many servers to not support this (such where the home is not a real > physical entity, but just an entry point into e.g. a DB). > > Yet another approach would be to just PUT a non-calendar resource with > the config into the home. But again, this will only work in a few servers. > > One thing which would work universally for the client, is taking another > URL (pattern) where the client can store config information. Then the > admin of the backend server could decide where user configuration should > go. (direct it to the principal, to the home or some other, regular DAV > store). > > Summary: There is no interoperability on this :-/ Agreed. For the record our server does not support PROPPATCH of dead properties on a principal resource. With our delegate support we do allow PROPPATCH of group-member properties on the delegate resources which are children of the principal. I do think using WebDAV properties for preferences is not the best solution. In Mulberry, as a replacement for IMSP and ACAP, I ended using a simple WebDAV PUT of a properties document to a "regular" WebDAV server (not that our calendar server does not support non-calendar/address data puts in a home). The benefit of using a resource rather than properties is that conflicts can be detected (etag conditions) - that is important because multiple clients are involved. That said, it is still not ideal in that it would be nice to be able to do partial updates - but PATCH could take care of that. In any case, I suggest telling the client folks to try PROPPATCH on principals, if that fails, try the calendar home, if that fails try the default calendar (which is not ideal because it could be deleted), if that fails - fail gracefully! -- Cyrus Daboo _______________________________________________ tc-caldav-l mailing list tc-caldav-l(a)lists.calconnect.org http://lists.calconnect.org/mailman/listinfo/tc-caldav-l -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CalDavZAP and settings
by Ken Murchison 10 May '13

10 May '13

Hmm. I haven't seen Apple iCal do a PROPPATCH on anything but individual calendars or the calendar-home-set. I will see the Apple, DaviCal, Bedework, Oracle, and AOL developers the first week of June at the next CalConnect event and I will bring this up as a topic of discussion to formulate some recommended best practices. BTW, other than my few nit-picks, both of your clients look great and I will be recommending them as add-ons for our server. Keep up the good work! On 05/10/2013 01:48 AM, Ján Máté wrote: > Hi Ken, > > we use the same approach as Apple ... yes, it is not required, but usually it works. > > > JM > > On May 10, 2013, at 1:15 AM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> Hello, >> >> I see that the client tries to store its settings with a PROPPATCH on DAV:current-user-principal. Per RFC 3744, a server isn't required to support PROPPATCH on principal resources, which the client can probably deduce from DAV:current-user-privilege-set. I wonder if doing the PROPPATCH on CALDAV:calendar-home-set would make more sense. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

1 0

CalDavZAP and settings
by Ken Murchison 10 May '13

10 May '13

Hello, I see that the client tries to store its settings with a PROPPATCH on DAV:current-user-principal. Per RFC 3744, a server isn't required to support PROPPATCH on principal resources, which the client can probably deduce from DAV:current-user-privilege-set. I wonder if doing the PROPPATCH on CALDAV:calendar-home-set would make more sense. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

CalDavZAP calendar creation
by Ken Murchison 09 May '13

09 May '13

Hello, Are there any plans to allow this client to create calendars using either MKCALENDAR or MKCOL? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

CalDavZAP: missing PRODID
by Ken Murchison 09 May '13

09 May '13

Hello, I just started testing this client with the CalDAV server that we are developing and I noticed that when creating an iCalendar object, the required PRODID property is missing. This violates RFC 5545 (and even the obsolete RFC 2445). -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Sabre_DAV_Exception_ReportNotSupported
by Florian Rauscher 12 Apr '13

12 Apr '13

Hi to all, I use ownCloud 5 with CalDavZAP last stable release. CalDavZAP can ... ... connect to ownCloud ... read the calendars from ownCloud ... write events to ownCloud (i can see it on ownClounds own calendar) but CalDavZAP can't read events. ownCloud use SabreDAV 1.7.5, i get in Firebug this error REPORT: http://user:pass@192.168.1.1/owncloud/remote.php/caldav/calendars/user/defa… 403 Forbidden Answer body: <d:errorxmlns:d="DAV:"xmlns:s="http://sabredav.org/ns"> <s:exception>*Sabre_DAV_Exception_ReportNotSupported*</s:exception> <s:message></s:message> <s:sabredav-version>1.7.5</s:sabredav-version> <d:supported-report></d:supported-report> </d:error> is there any way to get CalDavZAP to run with ownCloud. /owncloud/remote.php/caldav/principals/user/ gives return: calendar-proxy-read Proxy-Read, Principal calendar-proxy-write Proxy-Read, Principal

2 10

CalDavZAP 0.9.0 rc1 + CardDavMATE 0.11 rc2 available
by Ján Máté 10 Apr '13

10 Apr '13

Hi all, after several months of hard work we have a good news for you :-) CalDavZAP 0.9.0 release candidate 1 with completely new Todo interface and a ton of other improvements/fixes available at: http://www.inf-it.com/CalDavZAP_0.9rc1.zip demo: http://www.inf-it.com/caldavzap-next/ changelog: http://www.inf-it.com/caldavzap-next/changelog.txt CardDavMATE 0.11 release candidate 2 also with lot of improvements/fixes available at: http://www.inf-it.com/CardDavMATE_0.11rc2.zip demo: http://www.inf-it.com/carddavmate-next/ changelog: http://www.inf-it.com/carddavmate-next/changelog.txt If nobody reports any problem in ~1 week we will update some missing translations and will release the next public version of both clients. Many thanks for your feedback! JM

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients