Все-таки правильно, когда в телефоне полноценная ось и полноценный софт. Трещишь себе в жаббере, поигрываешь в игрушку, фоткаешь окрестности, тут же рассылая фотки всем желающим. Можно даже музычку послушать и кинцо посмотреть, не говоря уж о такой банальщине, как пописывание в бложек. Жаль, очень жаль, что нокия сотоварищи не померли десяток лет назад.

Потратил несколько дней (с перерывом "на подумать" в две недели) на то что б понять, что django-admin хоть и можно допилить для поддержки couchdb, но занятие это:

• А. Абсолютно неблагодарное. Django-admin испрещён query-set'ами, id-шки подразумевает только числовые, пытается сортировать, фильтровать и пейджить абсолютно несовместимым с couchdb пейджером и прочая, и прочая.
• Бэ. Чуть более, чем полностью, ненунжное. Django-admin предоставляет классную возможность для стартующего проекта. Вместо редактирования базы данных через PMA и ему подобное, django-admin даёт удобный интерфейс для порождения сущностей, а главное - связанных сущностей, кое является большой головной болью в SQL-ориентированных базах. Глупо и бессмысленно - вначале мы денормализуем наши данные по максимуму, а потом имеем головную боль, как их собирать обратно. Сами же себе ставим палки в колёса, вместо того что бы поменять парадигму.

После нескольких дней активного исследования, в голову пришла мысль - а что, собственно, сэкономит мне django-admin по сравнению с уже существующим удобным механизмом - futon'ом?

• Создание предопределённых сущностей. Спасибо, приплыли. CouchDB у нас, всё что у нас может быть предопределено - правило генерации id-шек и пара полей (например, type, определяющий сущность). Причем половина полей будет сложных типов, которые django-admin, как и django-forms не в состоянии будут ни отобразить, ни обработать. Значит придётся делать свои классы полей "JSONField" с соответствующей валидацией ("this is not valid json object"). Очень напоминает futon :)
• Разделение сущностей вместо навигации по длиннющему списку объектов. Секунду, а как это сделать? Написать view-функцию под каждую сущность (entity1/list, entity2/list) и скормить её в Admin-класс, что б нужный раздел админки выводил только нужные документы. Стоп, то же самое сделает и futon.
• Пейджинг? Хаха. Ничего альтернативного futon'у не получится при всём желании. Ну нету у нас страниц, да и впринципе они не нужны. Назад-вперёд - наше всё
• Сортировки? Фильтры? Поиск? К сожалению, от всего это пришлось отказаться, сделав ставку на CouchDB.

Итого, моя реализация django-admin будет, в лучшем случае, подобием futon'а. В более вероятном случае - будет плохим подобием. Так как django-admin с большим трудом может заменить обычную нормальную среднестатистическую админку (из десятка написанных с использованием django проектов, ни один не использовал django-admin в качестве интерфейса администратора, везде было нужно гораздо большее, чем редактирование связанных сущностей).

Вывод: не стоит тратить время. При старте проекта - futon и только futon. Впоследствии - нормальная, полноценная админка, ничего общего с django-admin не имеющая.