# Предметная область source и подкасты

## TL;DR Вывод

Добавить еще одно измерение полезно, когда мы знаем, куда будет двигаться развитие сорцов. Но мы не знаем. Поэтому делаем как проще.

Оставляем поле `type` ответственным за то, чтобы отвечать на оба вопроса

- как парсить поле `data`
- как качать ресурсы
- как интерпретировать результат

## Проблема (или нет)

Смущает, что мы пытаемся создать клон типа "rss".

Сейчас есть поле `type` которое отвечает на вопрос «как мне скачать данные». Оно не говорит о том, как отобразить посты.

Source.type = rss | crawler | fulldive

На планировании мы пришли к тому, что будет тип сорцов, который будет работать не в тех же сценариях, что и РСС. Например, такие сорцы будут фильтроваться для отдельной выдачи. Технически решение выглядит приводит к такому изменению

source.type =    rss   | podcast  | crawler | fulldive
source.data =    (all the same)   |   ...   |   ...

К чему это приводит. Мы будем добавлять в if-ы дополнительное условие о том, что надо вызывать один и тот же фетчер для подкастов и РСС. Зачем тогда это разделение на этапе скачивания?

Подкаст — это подмножество РСС. Технического отличия нет. Есть только бизнесовое отличие. Разница появляется тогда, когда надо отобразить эпизоды подкастов вместо новостей. Что если таких сценариев еще прибавится?

## Контр-проблема

Зачем серверу знать про разницу в фетчинге и отображении? Мы просто храним тип фида и типозависимвые особенности. Маппинг фетчинга и отображения лежит на клиенте.

## Модель данных

### Как сейчас сделано

Source {
    type = rss  // качать РСС и интерпретировать как текст с картинкой
    data = {
        url = "..."
    }
}

Source {
    type = podcast  // качать РСС и показывать как эпизоды подкаста
    data = {
        url = "..."
    }
}

Source {
    type = crawler // качать с помощью webview и показать как там надо
    data = {
        url = "..."
    }
}

Source {
    type = fulldive // пойти в апи авторизованным клиентом, получить ресурсы
    data = {
        ...
    }
}

### Вариант РСС-специфики

Сработает, если мы уверены, что данные подкаста и общего случая РСС не разойдутся

Source {
    type = rss                      // надо качать РСС
    data = {
        interpretation = generic    // интерпретировать как посты/новости
        url = "..."
    }
}

Source {
    type = rss                      // надо качать РСС 
    data = {
        interpretation = podcast    // интерпретировать как эпизоды с аудио
        url = "..."
    }
}

Source {
    type = crawler // качать с помощью webview и показать как там надо
    data = {
        // дополнительных интерпретаций нет
        url = "..."
    }
}

Source {
    type = fulldive // пойти в апи авторизованным клиентом, получить ресурсы
    data = {
        // дополнительных интерпретаций нет
        ...
    }
}