[kronolith] Shared Calendars

[Rick Stevens]

Jan Schneider wrote:
> Zitat von Pete Schwamb <pete@the-valley.org>:
> 
> 
>>I have a few ideas I'm not sure are part of the plan, so here they are:
>>1. We'd like to allow users to 'subscribe' to other event lists, such as 
>>holidays, or project schedules, or organization events.  These events 
>>would automatically show up on the users calendar, but not be editable 
>>by them.  The event lists would be managed much like a personal 
>>calendar, by someone authorized to do so.
> 
> 
> We already had some discussions about this feature in the past. You'll find
> a thread in the archive about holidays that covers most of the aspects like
> how to fetch event, where to keep the event data and how to mark event data
> as being public.

Well, as I mentioned to Chuck in a response (which I stupidly forgot to
CC the list on--I'll remedy that next), I have a specific need for the
ability to query another user's calendar and possibly set an appointment
on it PDQ (pretty d*mned quick).  Once I have the nagging users off my
posterior, I can generalize it more.

However, to address your concerns:

> 1) Implement multiple sources. Similar to like we have it in Turba now, make
> it possible to define multiple (local) sources that are all showed together
> in the users calendar at once (in opposite to Turba).

That's a generalized version of what I want to do and my intent is to
provide that feature set.  Right now, I'm working with a specific set of
requirements and support ("$vdomain"s and calendar stored on SQL).  I'm
the first to admit I'm not an HTML or PHP programmer (I'm a C, C++
geek), so I must start with baby steps or I'll fall over on my rather
large nose.

> 2) Implement basic calendar rights, like read-only public calendars with
> write rights only for admins. Again like in Turba.

Again, more generalizations.  I'll look at Turba more closely regarding
sources.  I would like to see those features myself.  Time, time, time!
I need more time!

> 3) Make calendars suscribeable by the users.

In my model currently, you are automatically subscribed to other
people's calendars if they're in your $vdomain AND they've set the
"peek_at" attribute on their calendars.  If they've also set the
"appt_ok" attribute, you can set an appointment on their calendar.

I suppose the list of subscribable calendars could be done via $realm,
but I've not gotten that far in my thinking.

> 4) Implement remote sources based on our rpc client/server as proposed in
> the holiday thread.

I'll have to look at that thread.  I wasn't aware of it.

> 5) Build a gcal based holiday subscription service on horde.org again as
> proposed in the holiday thread.

Well, that's beyond my perusal at the moment.  If I get this beast
running and generalized to the point that you and Chuck and the rest
of the gang think I'm on the right track, I'll take a whack at it.  My
initial go at this was to provide a full Hordeified gcal server, but the 
time crunch prevents me from pursuing it at this time.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-  Time: Nature's way of keeping everything from happening at once.  -
----------------------------------------------------------------------