Hi Ján, hi list
First of all, thanks for your great job! And sorry for my poor english
Today, we use Agendav (www.agendav.org) for our users. I follow your work since the first release.
We need features before migrate from Agendav to CaldavZap in a near future. Maybe it's already in your roadmap? (if not, can you give us your point of view? I read that you work first on the performance issues)
- Agendav allow users to share their own calendar(s) directly to other users present in the davical server database. We like this feature because the davical admin frontend is too complex for basic users.
- Is-there a way to let the user to choose the color of his calendars. Usefull for groups: each member can select the color of his choice for the team calendar. This feature is not server-dependant (i know that the color can be transmitted to the caldav server but this is not what we want)
- Permit users to include external calendars ( .ics ) directly via caldavzap web frontend. Actually it seems possible only via config files.
- Permit users to create calendars (already discussed in caldavzap mailing list). I think that it's already in the roadmap.
- Forced Refresh button without waiting. ( F5 disconnect the user)
Regards;
Adrien
Hi Adrien,
On Aug 28, 2013, at 12:27 PM, Adrien MALGOYRE malgoyre@pytheas.univ-amu.fr wrote:
Hi Ján, hi list
First of all, thanks for your great job! And sorry for my poor english
Today, we use Agendav (www.agendav.org) for our users. I follow your work since the first release.
We need features before migrate from Agendav to CaldavZap in a near future. Maybe it's already in your roadmap? (if not, can you give us your point of view? I read that you work first on the performance issues)
- Agendav allow users to share their own calendar(s) directly to other users present in the davical server database.
We like this feature because the davical admin frontend is too complex for basic users.
I really don't know how this "sharing" works ... do you have any technical documentation or hints about this feature? If it is supported directly by DAViCal we can add it, but if it is "hardcoded" into Agendav database, then there is no way to add it (our client is pure JavaScript).
- Is-there a way to let the user to choose the color of his calendars. Usefull for groups: each member can select the color of his choice for the team calendar.
This feature is not server-dependant (i know that the color can be transmitted to the caldav server but this is not what we want)
Currently we support only sever-side color (stored as dav property) and we have plan to add support for editing it. The main problem is, that if we add support for server-side color management, I have no idea how to not confuse users with another "local color" management.
- Permit users to include external calendars ( .ics ) directly via caldavzap web frontend. Actually it seems possible only via config files.
It is not possible in pure JavaScript ... the server where the .ics file is stored MUST returns proper CORS headers and this not true for 99.9% of servers :-/ So the only way to share .ics files is usually a local proxy (and it must be set by the server administrator).
- Permit users to create calendars (already discussed in caldavzap mailing list). I think that it's already in the roadmap.
Will add in future.
- Forced Refresh button without waiting. ( F5 disconnect the user)
There are major changes in synchronization in the upcoming versions of both clients. These changes allows you to use much smaller sync-interval without affecting the server performance. Personally I don't want to allow users to perform manual synchronization, because if you have lot of stupid users then they can DDOS your server by clicking to "reload" every few seconds (experience from real environment). So currently there is no plan to add manual refresh option, but if we get lot of request to add this feature we will add it.
JM
p.s.: feature highlights from the next versions:
CalDavZAP: - major synchronization changes - instead of N (or 2N in worst case) requests we perform only 1 (or 1+N in worst case) requests [N = number of collections, worst case = there is at least one change in each collection] - support for time-range synchronization (only limited number of events are downloaded, the rest are downloaded if you click to future or past) => MAJOR performance improvement - minor GUI changes
CardDavMATE: - major synchronization changes - instead of N (or 2N in worst case) requests we perform only 1 (or 1+N in worst case) requests [N = number of collections, worst case = there is at least one change in each collection] - support for simultaneous collection displaying - major GUI changes (e.g.: addressbook colors)
Regards;
Adrien
Hi Ján,
Hi Adrien,
On Aug 28, 2013, at 12:27 PM, Adrien MALGOYRE malgoyre@pytheas.univ-amu.fr wrote:
Hi Ján, hi list
First of all, thanks for your great job! And sorry for my poor english
Today, we use Agendav (www.agendav.org) for our users. I follow your work since the first release.
We need features before migrate from Agendav to CaldavZap in a near future. Maybe it's already in your roadmap? (if not, can you give us your point of view? I read that you work first on the performance issues)
- Agendav allow users to share their own calendar(s) directly to other users present in the davical server database.
We like this feature because the davical admin frontend is too complex for basic users.
I really don't know how this "sharing" works ... do you have any technical documentation or hints about this feature? If it is supported directly by DAViCal we can add it, but if it is "hardcoded" into Agendav database, then there is no way to add it (our client is pure JavaScript).
I just checked this code : https://github.com/adobo/agendav
To display the principals list, an XML search is done using the davical server.
After that, the Agendav PHP code use the following function : caldav->setacl to share a resource.
The XML request is describe in web/application/libraries/Caldav.php
I'm not a dev expert, you might take a look !
- Is-there a way to let the user to choose the color of his calendars. Usefull for groups: each member can select the color of his choice for the team calendar.
This feature is not server-dependant (i know that the color can be transmitted to the caldav server but this is not what we want)
Currently we support only sever-side color (stored as dav property) and we have plan to add support for editing it. The main problem is, that if we add support for server-side color management, I have no idea how to not confuse users with another "local color" management.
OK
- Permit users to include external calendars ( .ics ) directly via caldavzap web frontend. Actually it seems possible only via config files.
It is not possible in pure JavaScript ... the server where the .ics file is stored MUST returns proper CORS headers and this not true for 99.9% of servers :-/ So the only way to share .ics files is usually a local proxy (and it must be set by the server administrator).
Understand
- Permit users to create calendars (already discussed in caldavzap mailing list). I think that it's already in the roadmap.
Will add in future.
Cool
- Forced Refresh button without waiting. ( F5 disconnect the user)
There are major changes in synchronization in the upcoming versions of both clients. These changes allows you to use much smaller sync-interval without affecting the server performance. Personally I don't want to allow users to perform manual synchronization, because if you have lot of stupid users then they can DDOS your server by clicking to "reload" every few seconds (experience from real environment). So currently there is no plan to add manual refresh option, but if we get lot of request to add this feature we will add it.
Ok this is a good news.
Thanks for all
Adrien
JM
p.s.: feature highlights from the next versions:
CalDavZAP:
- major synchronization changes - instead of N (or 2N in worst case) requests we perform only 1 (or 1+N in worst case) requests [N = number of collections, worst case = there is at least one change in each collection]
- support for time-range synchronization (only limited number of events are downloaded, the rest are downloaded if you click to future or past) => MAJOR performance improvement
- minor GUI changes
CardDavMATE:
- major synchronization changes - instead of N (or 2N in worst case) requests we perform only 1 (or 1+N in worst case) requests [N = number of collections, worst case = there is at least one change in each collection]
- support for simultaneous collection displaying
- major GUI changes (e.g.: addressbook colors)
Regards;
Adrien
Hi Adrien,
On Sep 3, 2013, at 1:40 PM, Adrien Malgoyre malgoyre@pytheas.univ-amu.fr wrote:
- Agendav allow users to share their own calendar(s) directly to other users present in the davical server database.
We like this feature because the davical admin frontend is too complex for basic users.
I really don't know how this "sharing" works ... do you have any technical documentation or hints about this feature? If it is supported directly by DAViCal we can add it, but if it is "hardcoded" into Agendav database, then there is no way to add it (our client is pure JavaScript).
I just checked this code : https://github.com/adobo/agendav
To display the principals list, an XML search is done using the davical server.
After that, the Agendav PHP code use the following function : caldav->setacl to share a resource.
The XML request is describe in web/application/libraries/Caldav.php
I'm not a dev expert, you might take a look !
I checked AgenDAV source code but it looks mysteriously, in the source code I found:
CREATE TABLE shared ( sid int NOT NULL DEFAULT nextval('shared_sid_seq'), user_from varchar(255) NOT NULL, calendar varchar(255) NOT NULL, user_which varchar(255) NOT NULL, options text NOT NULL DEFAULT '', write_access boolean NOT NULL DEFAULT '0', PRIMARY KEY (sid) );
but AgenDAV is also able to alter server privileges (there are some ACL and PROPPATCH related functions) - so I am not sure how exactly the sharing works.
What we can do is to add support for ACL manipulation using DAV requests (we will very probably add it in future).
JM
Hi Ján
I checked AgenDAV source code but it looks mysteriously, in the source code I found:
CREATE TABLE shared ( sid int NOT NULL DEFAULT nextval('shared_sid_seq'), user_from varchar(255) NOT NULL, calendar varchar(255) NOT NULL, user_which varchar(255) NOT NULL, options text NOT NULL DEFAULT '', write_access boolean NOT NULL DEFAULT '0', PRIMARY KEY (sid) );
The shared table is only used for shared calendars (no support of "groups"). The soft is not able to detect ACL between users when user_from; calendar and user_wich columns are empty. "Options" columns permit to add some local parameters (colors etc.)
I will do some tests, but I'm quite sure that the "acl" function does not use this SQL table. It's also true for detection of user list.
Adrien
but AgenDAV is also able to alter server privileges (there are some ACL and PROPPATCH related functions) - so I am not sure how exactly the sharing works.
What we can do is to add support for ACL manipulation using DAV requests (we will very probably add it in future).
JM