O problema silencioso com feeds iCal (e o que os substitui)

Pelos últimos vinte anos, a resposta para "como publico um calendário" tem sido: gere um arquivo ICS, coloque-o atrás de uma URL, diga às pessoas para se inscrever.

Funciona. Tem funcionado desde 1998. Mas qualquer um que realmente executou uma série de eventos ao vivo de um feed ICS bruto conhece os modos de falha silenciosa — aqueles que não aparecem até você estar seis meses dentro e se arrependendo do setup.

Aqui está o que são, e o que um grupo broadcast substitui.

Problema 1: Você não consegue editar um evento

Um feed ICS bruto é geralmente gerado na publicação — você configura a URL, empurra eventos, eles sincronizam. Quando você precisa corrigir um erro de digitação, mover uma hora, ou cancelar uma sessão, o cliente realmente tem que re-buscar o feed e honrar a atualização.

Na prática: alguns clientes honram a atualização baseada em UID. Alguns não e deixam o evento antigo assombrado nos calendários para sempre. Alguns apenas duplicam. Você descobre por e-mail ("ei, seu 19h está aparecendo duas vezes para mim") e não há boa resposta.

Um grupo broadcast gerencia UIDs de evento e atualizações corretamente. Edições são edições. Cancelamentos são cancelamentos. O feed é versionado.

Problema 2: Você não consegue deixar um assinante pular um evento

Num feed ICS bruto, cada assinante vê cada evento. Se alguém ama a série mas não consegue fazer a terça próxima, suas únicas opções são: deletar manualmente o evento (e ter ele voltar na próxima sincronização), ou desinscrever-se do feed inteiro.

Ambas as opções são ruins. A primeira é confusa. A segunda perde um assinante por um conflito.

Grupos broadcast suportam opt-out por evento. O assinante toca um link único, aquele evento desaparece do feed deles apenas, e o resto da série fica intacto.

Problema 3: Você não tem senso de quantas pessoas se inscreveram

Uma URL estática ICS é um arquivo servido por um webserver. Se você olha os logs de acesso pode estimar, mas a maioria dos organizadores de evento não. Você não sabe se tem 10 assinantes ou 10.000.

Grupos broadcast dão a você uma contagem anônima de assinantes — sem e-mails, sem identidades, apenas "aqui está quantos calendários isso vive em." Esse número sozinho muda como você executa a série.

Problema 4: Aplicativos de calendário aceleram ou armazenam em cache agressivamente

Google Calendar famosamente atualiza feeds ICS externos em seu próprio cadência — às vezes diariamente, às vezes muito mais lento. Apple Calendar é mais rápido mas não instantâneo. Outlook é... Outlook.

Isso não é algo que você consegue corrigir do lado do feed; os apps controlam o refresh. Mas com um feed broadcast que inclui atualizações VEVENT iCalendar por evento e números de sequência apropriados, o refresh que acontece se propaga corretamente. Com um ICS hand-rolled, frequentemente não.

Problema 5: Não há desinscrição graciosa

Um feed ICS, uma vez inscrito, fica no calendário do assinante até eles se lembrarem como remover. A maioria dos apps esconde esse UI cinco menus de profundidade. Do lado do organizador, não há forma de desinscrever alguém que reporta abuso, nenhuma forma de revogar uma única inscrição sem quebrar o feed para todos.

Grupos broadcast têm uma desinscrição de um toque na experiência do assinante, e o organizador pode regenerar o link de compartilhamento se algo der errado.

O que você mantém

Tudo que um feed ICS fez bem — anônimo, universal, mão única, offline-capaz, sem necessidade de login — um grupo broadcast mantém. O transporte subjacente ainda é iCalendar; cada app de calendário já sabe como lê-lo. O que muda é a camada operacional ao seu redor: edição, optando, contagem, revogação.

Se você está publicando uma série de eventos recorrentes e você já teve que responder um e-mail "o evento desapareceu do meu calendário", este é o caminho de upgrade.