Package org.exoplatform.caldav.service

Class CaldavReadService

java.lang.Object
org.exoplatform.caldav.service.CaldavReadService
@Service public class CaldavReadService extends Object
Reads the connected account's calendars server-side, so the page receives mapped events instead of downloading and parsing every iCalendar object in the main thread.

One REPORT per calendar per request, bounded by how many calendars the account holds — a handful. Not one per event: that is the shape this replaces.

  • Constructor Details

    • CaldavReadService

      public CaldavReadService()

  • Method Details

    • listCalendars

      public org.exoplatform.caldav.model.RemoteCalendarsRead listCalendars(long userIdentityId, String username)
      The calendars of the connected account, and whether the account could be asked at all.

      The failure travels in the answer rather than as an exception. A caller that receives a bare empty list cannot tell an account holding no calendar from an account whose server is down, and the second is the case that actually happens — so it is said, next to the list, instead of being left in a log line no browser reads.

      Parameters:
      userIdentityId - identity of the user
      username - their eXo login, which the credentials provider maps to their account on the server
      Returns:
      the calendars, each with a usable colour, and the flag saying whether the listing failed; empty and unfailed when no account is connected

    • describeCollections

      public org.exoplatform.caldav.model.RemoteCalendarsRead describeCollections(long userIdentityId, String username, Set<String> hrefs)
      The named collections of the connected account, bound or not, each classified and named as listCalendars(long, java.lang.String) would have listed it (EXO-90239).

      What the hidden-calendars listing asks. A hidden calendar is bound by construction — the binding is what hides it — so listCalendars(long, java.lang.String), which serves the unbound, can never describe one; and the drawer that offers it back needs what the list would have said about it: the name the server gives it today, whether it is a share, and whose. Answered from the same listing, the same classification and the same owner lookup the list uses, so a calendar reads the same on its way out of the agenda as on its way back in. Neither the bound filter nor the mirror exclusion applies: the caller names what it wants to hear about, and hears about those the server still lists. A collection absent from the answer is one the account no longer holds — or, when failed says so, one nothing could be asked about.

      Parameters:
      userIdentityId - identity of the user
      username - their eXo login, which the credentials provider maps to their account on the server
      hrefs - the collection paths to describe, canonical
      Returns:
      the collections the server still lists among those named, in the shape of the calendar list, beside the flag saying whether the listing failed; empty and unfailed when nothing was asked or no account is connected

    • readEvents

      public org.exoplatform.caldav.model.RemoteEventsRead readEvents(long userIdentityId, String username, Instant start, Instant end)
      The events of the connected account over a window, one calendar at a time, and which part of that reading failed.

      A calendar that fails degrades to no events for that calendar, exactly as the browser's Promise.allSettled did: one collection a server refuses, or one object it cannot serialise, must not blank the whole agenda. The failure is still not raised, because the user's remaining calendars are worth showing — but it is now reported, in the answer, because a caller handed only the surviving events draws them as the whole truth and says nothing is missing.

      Two grains, matching the two ways a read fails. The account could not be asked at all — nothing was read, and the empty list is not an answer about the user's week. Or the account answered and some of its collections did not, in which case the events of the others are returned and only the failed hrefs are named.

      Parameters:
      userIdentityId - identity of the user
      username - their eXo login, which the credentials provider maps to their account on the server
      start - beginning of the window
      end - end of the window
      Returns:
      the occurrences, each tagged with the calendar it came from, beside the flag and the hrefs that say what was not read