Ipfs: переименовать *-ipfs-api в *-ipfs-http-client ??

Go может сделать это, когда мы закончим CoreAPI и перепишем клиент... (иначе мы сломаем импорт).

Назвав его -client , он звучит так, как будто данный модуль является клиентом IPFS (что-то, что говорит о битовой перестановке/и т. д., но не может ничего обслуживать). Если вы хотите, чтобы у него было однозначное имя, я бы предложил -api-client , хотя оно и длиннее.

Хм. Да, у тебя есть хорошая мысль.

Мне кажется разумным.

Если мы рассматриваем -api-client, я думаю, что -http-client может быть более очевидным.

поддержите этот комментарий, если вы согласны с переименованием *-ipfs-api в *-ipfs-http-client

Я за своего клиента ! Я мог бы оставить старое имя с предупреждением, чтобы ничего не сломать.

Кажется, мы набрались кворума :) Теперь осталось их везде переименовать :)

Библиотека PHP также может общаться с сокетом... поэтому переименование будет неправильным на 💯%

Сообщение в блоге @alanshaw https://blog.ipfs.io/58-http-client-rename/ \o/

почему бы не просто «ipfs-api-client»? привязка его к http определенно кажется... противоположной

@whyrusleeping В настоящее время это только http, что меня удивило, когда я впервые начал работать с IPFS. Я рад, что теперь стало ясно, что на данный момент клиенты обычно используют протокол HTTP.

Кажется, у меня нет прав на переименование, https://github.com/ipfs/java-ipfs-api
Может ли кто-нибудь предоставить их мне?

@ianopolous сделал тебя админом :)

Два цента от кого-то из далекой-далекой галактики (не совсем, libp2p)...

ipfs-api-client для меня избыточен, потому что: как еще клиент мог бы общаться со службой, если не через API (каков бы ни был интерфейс и формат провода)? РЕДАКТИРОВАТЬ: просто прочитайте комментарий @alexander255 выше, и это тоже имеет смысл. -api-client дает понять, что это SDK, а не клиентское приложение.

Включение фактического типа интерфейса (http) в имя недальновидно IMO:

1. Мы не хотим организовывать еще одно массовое переименование после введения поддержки сокетов Unix, именованных каналов Windows, gRPC и т. д.
2. В будущем мы можем использовать RPC-библиотеку libp2p, которая по умолчанию будет мультитранспортной.
3. Независимо от того, осуществляется ли доступ к резервной службе через HTTP, gRPC, сокеты Unix и т. д., интерфейсный API останется прежним. Гипотетические модули ipfs-api-[ipc/http/grpc]-client будут дублировать большой объем кода.

ipfs-client кажется мне подходящим, используя дизайн, похожий на адаптер, для выбора серверных частей HTTP, IPC, gRPC при предоставлении того же внешнего интерфейса.

Из предложений и аргументов на данный момент мне нравится это больше всего, но ipfs-client читается так, как будто это просто приложение/инструмент. Если мы можем предположить, что они всегда в виде библиотек, как насчет ipfs-client-library или ipfs-client-lib ?

@raulk Для меня просто ipfs-client звучит так, как будто на самом деле содержит клиентскую реализацию ipfs. Что вводит в заблуждение.

Полностью согласен с тем, что помещать http в заголовок очень недальновидно. Было бы здорово, если бы далеко идущие решения, подобные этому, обсуждались немного больше, прежде чем принимать их так широко.

@whyrusleeping По крайней мере, для http-клиента Java это всегда будет именно http-клиент. Если есть какой-то другой протокол, на котором может основываться клиент, то это будет другой проект. Все может быть по-другому для клиента go, который уже объединяет http с вызовами на основе строки cmd.

@ianopolous Я уверен, что клиент java API можно легко настроить для работы через веб-сокеты, и заставить его также работать через сокет домена unix тоже не кажется слишком надуманным. Не могли бы вы сделать все это в разных пакетах?

@whyrusleeping Я никогда не видел java sdk для какой-либо службы, использующей веб-сокеты, если бы мне нужно было что-то подобное, я бы просто использовал обычный сокет. Если бы это было полезно для ipfs, и было много дублирования кода с http-клиентом, то лично я бы выделил общий код в библиотеку (и в идеале сделал бы ее еще более независимой от протокола).

Обратите внимание, что смешивание двух разных протоколов в одном клиенте может привести к путанице и ошибкам: https://github.com/ipfs/go-ipfs/issues/5784 .

@ianopolous Давайте пока отложим обсуждение веб-сокетов и предположим, что нам нужны клиентские SDK, которые могут поддерживать несколько внутренних интерфейсов (какими бы они ни были).

Чтобы смоделировать это на Java, у вас обычно будет модуль core , который определяет скелет, общедоступный API, абстракции, DTO и т. д. И затем у вас будет любое количество модулей, каждый из которых добавляет поддержку другого бэкэнда. протокол. Все они реализуют интерфейс адаптера из core .

Обычно вы импортируете их в сборку с помощью <scope>runtime</scope> (Maven), а core могут даже использовать такой механизм, как SPI (интерфейс поставщика услуг), чтобы обнаружить, какие адаптеры доступны во время выполнения, и использовать оптимальный (даже выполняя какой-то запасной вариант или согласование). Или вы можете положиться на то, что пользователь укажет, какой из них использовать во время компиляции, например

ipfsClient.setBackend(HttpApiBackend.class);     // public void setBackend(Class<? extends IpfsBackend> clz);

Кстати, web3j поддерживает HTTP, IPC и WSS в одном и том же модуле Java, и, пока API хорошо смоделирован, единственное бремя, которое это добавляет, — это извлечение потенциально неиспользуемых зависимостей.

@raulk

предположим, что нам нужны клиентские SDK, которые могут поддерживать несколько внутренних интерфейсов (какими бы они ни были).

Я определенно не хочу этого. Помещение всех протоколов в одну библиотеку имеет несколько недостатков. Это делает размер библиотеки как в исходном, так и в двоичном виде O(N), где N — количество протоколов. Почти все время мне нужна только одна реализация протокола SDK, и я бы предпочел не иметь библиотеку, 90% которой мне чужды, раздувают мое приложение, но не оставляют мне простого способа его удалить. Кроме того, если я забочусь о безопасности и мне нужно проверить свои зависимости, это огромный выброс сложности и затрат без всякой причины.

Я не говорю, что такого универсального клиента не должно быть. Возможно, для этого есть вариант использования, но его не следует навязывать людям.

@ianopolous Я думаю, вы предполагаете модель uber-JAR. Я говорю об обратном: многомодульная сборка , где зависимости не просачиваются между модулями и извлекаются только тогда, когда конечный пользователь добавляет этот модуль в свою сборку. Например, вы можете проверить проект Apache Camel , в котором размещено более 200 адаптеров для различных технологий. Как пользователь, я добавляю верблюжье ядро ​​(очень тонкое) + компоненты, которые хочу использовать (верблюд-mqtt, верблюд-ftp и т. д.), и позволяю Maven/Gradle рассчитать для меня эффективный граф зависимостей.

я против переименования его в http-client . как я уже говорил, php-api-client может общаться с конечной точкой html или с сокетом. это просто другой драйвер , остальная часть кода полностью такая же. так что я на стороне того, что http-* не дальновиден. но я согласен с переименованием в LANG-ipfs-client или LANG-ipfs-api-client

Я полностью согласен с @digitalkaoz : это зависит, я думаю, от того, предусматривает ли данная клиентская библиотека поддержку других транспортов или нет. (В этом отношении библиотека Python, скорее всего, будет, так как в ней уже есть подключаемые транспорты, и мы можем легко иметь необязательные зависимости в языках сценариев.)

Это было сделано. Закрытие.

@Kubuxu давайте использовать для отслеживания миграции всех других пакетов. См. связанные вопросы.

Хорошо, извините за это.

Должны ли все клиентские реализации HTTP API теперь переименовываться в ipfs-http-client?

Кажется, несколько реализаций не последовали этому примеру, но сохранение этого открытым также не слишком помогает. Тем не менее, мы рекомендуем обновить имя, когда это возможно.