Третий вариант - распечатать (впрочем, это частный случай либо "поделиться", либо "бэкапа", в зависимости от способа, которым владеет печатающая программа). Разные варианты фильтров-обработчиков, впрочем, тоже можно считать частным случаем "поделиться".
Ещё можно рассмотреть такую операцию, как "задержать до определённого момента/снапшот". Которую также можно реализовать как создание ссылки (которая будет существовать, даже если другой клиент удалит контент).
Про зоопарк клиент-серверных протоколов и прибамбасов для обработки данных: Проблема тут не в том, что протокола нет, а в том, что информации стало очень много, её трудно искать и зарождается экономика основанная на обработке информации (и в частности на запрещении/затруднении к ней доступа техническими методами).
В конце концов, HTTP+WebDAV предоставляют приличное количество стандартных глаголов для управления контентом. И навесить их поверх USB достаточно просто. Но вот сидит какой-то архитектор или аналитик, читает записку "разработать механизм, что бы можно было фоточки скидывать не отмонтируя SD-карту", и думает: 1) зачем ему плодить лишнюю точку возможных подводных камней на стыке USB и HTTP_over_USB?; 2) чем заменить в новом протоколе host:port (т.е. потребуется сделать какую-то подсистему поиска/перечисления приложений/фоток на обоих сторонах)? 3) Как все эти сложности с обеспечением интероперабельности помогут (точнее, не помешают) заработать? И в результате рождается велосипед, который, хоть и коряво, но едет туда, куда нужно.
И так получается, даже если в исходной задаче для архитектора нет требования обеспечить явный lock-in. Просто недостаток времени и прочих ресурсов на изучение best practices приводит к тому, что если бы вдруг электроннной почты по каким-то причинам не было бы до сих пор, то сейчас она возникла бы в виде каких-нибудь "Google messages", которыми бы пользовались лишь пользователи гугла.
Нам лишь остаётся пытаться остаться на предыдущем уровне технологического уклада и как минимум сохранять на своих компьютерах традиционные файловые системы, rsync, программы, которые работают с файлами как с файлами, а не как своими личными БД и т.д.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2015-09-10 12:54 pm (UTC)Разные варианты фильтров-обработчиков, впрочем, тоже можно считать частным случаем "поделиться".
Ещё можно рассмотреть такую операцию, как "задержать до определённого момента/снапшот". Которую также можно реализовать как создание ссылки (которая будет существовать, даже если другой клиент удалит контент).
Про зоопарк клиент-серверных протоколов и прибамбасов для обработки данных: Проблема тут не в том, что протокола нет, а в том, что информации стало очень много, её трудно искать и зарождается экономика основанная на обработке информации (и в частности на запрещении/затруднении к ней доступа техническими методами).
В конце концов, HTTP+WebDAV предоставляют приличное количество стандартных глаголов для управления контентом. И навесить их поверх USB достаточно просто. Но вот сидит какой-то архитектор или аналитик, читает записку "разработать механизм, что бы можно было фоточки скидывать не отмонтируя SD-карту", и думает: 1) зачем ему плодить лишнюю точку возможных подводных камней на стыке USB и HTTP_over_USB?; 2) чем заменить в новом протоколе host:port (т.е. потребуется сделать какую-то подсистему поиска/перечисления приложений/фоток на обоих сторонах)? 3) Как все эти сложности с обеспечением интероперабельности помогут (точнее, не помешают) заработать? И в результате рождается велосипед, который, хоть и коряво, но едет туда, куда нужно.
И так получается, даже если в исходной задаче для архитектора нет требования обеспечить явный lock-in. Просто недостаток времени и прочих ресурсов на изучение best practices приводит к тому, что если бы вдруг электроннной почты по каким-то причинам не было бы до сих пор, то сейчас она возникла бы в виде каких-нибудь "Google messages", которыми бы пользовались лишь пользователи гугла.
Нам лишь остаётся пытаться остаться на предыдущем уровне технологического уклада и как минимум сохранять на своих компьютерах традиционные файловые системы, rsync, программы, которые работают с файлами как с файлами, а не как своими личными БД и т.д.