Calendaring system?

Clint Savage herlo1 at gmail.com
Mon Feb 9 22:08:24 UTC 2009


On Mon, Feb 9, 2009 at 2:23 PM, David Nalley <david at gnsa.us> wrote:
> On Mon, Feb 9, 2009 at 4:11 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
>> On Mon, 9 Feb 2009, David Nalley wrote:
>>
>>> On Mon, Feb 9, 2009 at 3:46 PM, Mike McGrath <mmcgrath at redhat.com> wrote:
>>> > On Mon, 9 Feb 2009, Clint Savage wrote:
>>> >
>>> >> On Mon, Feb 9, 2009 at 12:36 PM, Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
>>> >> > Adam Williamson wrote:
>>> >> >>
>>> >> >> Hi, guys. Uh, quick intro for those who see the redhat.com and wonder
>>> >> >> who I am - I'm Adam Williamson. I'm new in the Fedora QA department here
>>> >> >> at RH, my job is to drive community involvement in Fedora QA. I came
>>> >> >> over from Mandriva where I was the community manager. I'll be working
>>> >> >> from my home in Vancouver, Canada.
>>> >> >>
>>> >> >> I'm new on the list so this may have come up before, in which case
>>> >> >> apologies :). Something I thought would be nice to have for QA community
>>> >> >> is a public calendar system where dates of events like test days can be
>>> >> >> published. Obviously it's silly for me personally or the QA team to take
>>> >> >> on the job of hosting a calendar server, but it was suggested that it
>>> >> >> would be a good project for the infrastructure team, and other groups
>>> >> >> within Fedora could probably benefit from it. Does it sound like a good
>>> >> >> idea? Anyone want to have a go? Or is there something already, that I
>>> >> >> don't know about? Thanks!
>>> >> >
>>> >> > I've not seen anything in this thread yet, so it may have been mentioned
>>> >> > before;
>>> >> >
>>> >> > MediaWiki has a couple of calendering plugins that will allow "days" to be
>>> >> > allocated; I looked into this for our meeting schedule but since none of
>>> >> > them include any times for appointments I found it to be useless.
>>> >> > Nonetheless, it could be worthwhile for allocating "Test days" and "Events"
>>> >> > -and things of the sort.
>>> >> >
>>> >> > Kind regards,
>>> >> >
>>> >> > Jeroen van Meeuwen
>>> >> > -kanarip
>>> >> >
>>> >>
>>> >> I think the point I'm continuing to make is that it should support
>>> >> caldav or something similar.  The protocol defines a protocol, so the
>>> >> client applications themselves shouldn't matter, but we do need to
>>> >> have a way to communicate with the calendar server.
>>> >>
>>> >> My intention isn't to discount MediaWiki or Zikula as a possible
>>> >> platform for a calendaring client, but to say that the features you
>>> >> suggest are not what we're after here.  Instead I'd say that those two
>>> >> applications could push/pull data from the calendar server (using
>>> >> caldav).
>>> >>
>>> >> The events listed in the caldav server can be manipulated by these
>>> >> other applications and probably through an API which could include
>>> >> Access Control Lists based upon FAS rights.  I can see this being a
>>> >> bit of an undertaking, but it can really benefit the Fedora Project as
>>> >> a whole.
>>> >>
>>> >> As I stated in my previous email, I've got a draft up of all the
>>> >> features we'd like to see (it's pretty empty right now) and I'll
>>> >> probably go ahead and list some of this email there.  But for those of
>>> >> you who are interested in helping me get that wiki page more complete,
>>> >> feel free to visit:
>>> >>
>>> >> https://fedoraproject.org/wiki/User:Herlo/Fedora_Calendar_Project_Desired_Features_(Draft)
>>> >>
>>> >> Keep the thoughts coming, I want to see this project succeed!
>>> >>
>>> >
>>> > Maybe we should mature this a bit and look into full collaboration suites.
>>> >
>>> > For example http://www.opengroupware.org/
>>> >
>>> > I'm poking around at some now, I'm not sure what license restrictions
>>> > there are for each.
>>> >
>>> >        -Mike
>>> >
>>> > _______________________________________________
>>> > Fedora-infrastructure-list mailing list
>>> > Fedora-infrastructure-list at redhat.com
>>> > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>>> >
>>>
>>> As a former contributor to OGo I think it's a great project, and it
>>> supports things like CAlDAV. However unless things have changed
>>> recently I'd expect it to be a bear to get packaged and into Fedora.
>>> Not that it should be excluded, just a heads up. That said it's really
>>> email centric and I am not sure we'd want to get in that business.
>>>
>>
>> Lets say we wanted to use features that were _not_ email storage based.
>> How feasible is that?  For example, if I created an appointment for you
>> and me, it'd still send an email to your @fp.o email address which would
>> then just be forwarded to your local MTA.
>>
>>        -Mike
>>
>> _______________________________________________
>> Fedora-infrastructure-list mailing list
>> Fedora-infrastructure-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>>
>
> So OGo is (or was) cognizant of other users accounts - and would
> create the appointment on the calendar directly rather than sending to
> the users MTA. Calendar and other non-mail stuff are all stored in the
> DB - while mail is almost an add-on. (In the mail-less environment it
> knows about e-mail - and can send items out, but it treats local users
> completely separate from e-mail. That might be ok. - esp if we did
> iCAL or CalDAV.
>
> I do need to disclaim that I haven't kept up with OGo in quite a while
> and things may have changed, but the architecture had been around for
> a long time, and I don't think they would have made any dramatic
> changes.
>

Good call on OGO, I didn't even know it did iCal or caldav stuffs.  My
last job was extensively with OGO, but I was just a user.  It is
flexible, can handle multiple appointments, scheduling with one
another.  If it supports ical/caldav, it could be a very viable choice
as it wouldn't require the use of OGO, but it *could* be used to
schedule activities.

Sounds like we're narrowing our features down to a good list.  I'll
add OpenGroupWare onto the list.

Dave, could you expand on why it might be a bear to package?

Cheers,

Clint




More information about the infrastructure mailing list