Introduce Calendar API

[pawelkaczor]

A Calendar instance contains calendar events (instances of CalEvent) each identified by a name (String).

Calendar interface

case class ScheduledEvent(scheduledAt: ZonedDateTime, eventName: String, calendarEvent: CalEvent)

trait Calendar {
  def calendarEvents: Map[String, CalEvent]

  def upcomingEvent(ref: ZonedDateTme): Option[ScheduledEvent]

}

There could be different types of the calendar: DailyCalendar, WeeklyCalendar, MonthlyCalendar. The implementation of upcomingEvent method could be optimized for each calendar type.

[pawelkaczor]

@eikek WDYT?

[eikek]

Hi @pawelkaczor ,
While it is a nice idea, I don't think it fits into the scope of this lib :S. See I don't want to add more features; it's only parsing + generate the next time based on the calendar event expression. You could explore the calendar topic by its own library maybe (the core module has no other dependencies so it's quite lightweight to depend on it)? I can imagine many more things to come, like attendees, locations, ical etc. - and this is not the right place. Also it could work with cron expressions, too maybe (there is cron4s).

[pawelkaczor]

In general, I understand your point. I agree that the scope of the lib should be limited.

That's why I treat the Calendar API only as a generalization of CalEvent API that 1) can deal with sets of CalEvents 2) could benefit from optimizations. Calendar containing single CalEvent instance is equivalent of single CalEvent instance (and it is nothing more).

The CalEvent API could be replaced with Calendar API (but also both apis could be present).

Proposed Calendar domain has nothing to do with general/abstract Calendar domain. Notice that DailyCalendar, WeeklyCalendar concepts are nothing more than categorization of CalEvent sets requiring no additional information.

[pawelkaczor]

Also it could work with cron expressions, too maybe (there is cron4s).

Yes, you are right that Calendar could work also with cron based calendar events, so this is valid argument against adding Calendar to this project. But there also counter-arguments. calev-akka could support Calendars.

[eikek]

The CalEvent API could be replaced with Calendar API (but also both apis could be present).

I disagree. The CalEvent is really only the representation of the "*-*-* 12:00" kind of string, and it is natural to me to obtain the next matching date given a reference date from it, because this is the only reason it exists. The Calendar now involves names (Strings) and a map and a ScheduledEvent. I don't need all of this. This is more than what is here now; it's building on top of what this lib provides. I really think this should be its own project.

calev-akka could support Calendars.

To me this is again a reason for a separate project :-) Other submodules can't easily support it, so I think it's better in a separate project which can be more specialized for akka. However, it would be ok to me to add it to the akka submodule only.

[pawelkaczor]

OK. No problem. If I need this new Calendar stuff on my current project I will implement it somewhere else (not sure whether calev-akka is good place but thank you for the suggestion).

[eikek]

Thank you!