Adam Williamson wrote:
(My thinking is that probably there's going to be a fairly even split
between those who want to use a calendaring system from a web front
end
and those who'd prefer to use it from a desktop app, and unless we
cater
to both groups, it won't really work; for a project-wide calendering
project to have value, it needs wide buy-in, so you can really trust
that you can go to the calendering system and see ALL important
events,
and to do that, you need to cover at least the most popular use
cases).
if we really can't find anything that does both, though, we'll
probably
wind up picking a system that only does one, as you suggest.
One way to look at this problem is to separate those that need
read-only access to a calendar from those that need both read
and write capability.
In our organization we have few that write to calendars,
but many that consume calendar data.
( We don't use free / busy at this time )
We use a WebDAV server with iCal, Evo, or Sunbird / Lightening
for calendar editors, and then have a PHP script create read-only views
for everyone else.
read-write contributors => desktop app
read-only consumers => web app
I acknowledge that the distributed nature of Fedora contributors
might mean making the distinction between the needs of read-only
users vs. read-write users a non-starter, but it is something to
consider.
--
Charles Dostale
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
