in reply to Re^3: Managing a on-call Calendar
in thread Managing a on-call Schedule

I looked over GCal and it looks like what it is, a full-blown calendar system. So the questions move towards what almut asked for, what are my requirements?

GCal is a canned-product designed around individuals and events, and for sharing information. That is great for what it was designed,

  1. How do I implement business rules?
  2. How do I implement permissions, on individual calendars.
  3. How do I create new calendars to integrate with security?
  4. How do I integrate Google Calendar licensing with a product that I wish to license to others?

The time to address those questions there can easily surpass the amount of time it would take me to design something simple and effective for what I intend.

I have answered most of business logic issues with existing code. One of the few questions left was how to properly implement validations for the calendar.

In this case, I don't believe that GCal brings anything to the table for this problem. On the other hand, it is always nice to know of alternatives, I would never have thought about using GCal before you mentioned it.

G

Replies are listed 'Best First'.
Re^5: Managing a on-call Calendar
by dragonchild (Archbishop) on Feb 26, 2007 at 19:04 UTC
    The point wasn't that GCal solves your problem. The point is that you should first look at purchasing a solution rather than developing one because it's almost always going to be much cheaper for your employer to do so. Often, the difference is on the order of five to ten-thousand dollars (or euros or whatever).

    I have no idea what kind of applications are out there, other than Exchange/Outlook which does provide this kind of functionality. I'm sure there's other stuff that will do exactly what you want it to do.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Seekers of Perl Wisdom