Предложение о расширении Abilities в WordPress 7.1 вызвало сопротивление со стороны разработчика компонента из-за недостаточного тестирования

Предложение о добавлении трех новых read-only возможностей (abilities) в WordPress 7.1 вызвало «сильное сопротивление» со стороны одного из разработчиков Abilities API, который утверждает, что они не были должным образом протестированы и что на недавнем совещании WordPress AI Team был сделан вывод об их неготовности к включению в ядро.

Хорхе Коста, разработчик ядра, спонсируемый Automattic, опубликовал это предложение в блоге Make WordPress Core на прошлой неделе, призвав включить core/read-settings, core/read-content и core/read-users в релиз 7.1, выпуск которого запланирован на 19 августа во время WordCamp US.

Abilities API – это реестр, представляющий собой структурированный, машиночитаемый способ описания того, что может делать сайт. Он был включен в WordPress 6.9, расширен на браузер в версии 7.0 и разработан таким образом, чтобы агенты, инструменты автоматизации и плагины могли обнаруживать и вызывать функциональность через согласованный интерфейс, а не рыться по разрозненным функциям и эндпоинтам.

Предложение Косты предусматривает добавление в API возможностей ядра, охватывающих параметры, контент и пользователей — три самых базовых типа данных WordPress, чтобы инструменты, построенные на основе API, имели возможность запрашивать что-то осмысленное.

«Без возможностей чтения в ядре эти интеграции могут вызывать модель, но не способны надежно отвечать на базовые вопросы: какие посты существуют, какая страница является главной и т. д.», — написал Коста в своем предложении.

Все три возможности доступны только для чтения (read-only); чтобы открыть доступ агентам к параметрам и типам записей, потребуется включить флаг show_in_abilities — по аналогии с тем, как show_in_rest управляет доступом к REST API. По словам Косты, эти три новые возможности должны быть внедрены в ядро, поскольку в экосистеме уже разрабатываются конкурирующие реализации даже для таких базовых операций, как «получение поста», а общая конфигурация обеспечит единое место для проверки разрешений, структуры schema и граничных случаев.

Однако это предложение встретило «сильное сопротивление» со стороны старшего инженера из rtCamp Дэвида Левина, который входит в команду AI Team и является сопровождающим компонента Abilities API. Комментируя предложение, Левин написал, что только одна из трех возможностей, core/read-settings, была интегрирована в плагин WordPress AI, и это слияние было выполнено с предположением, что его сначала проверят и доработают. Он сказал, что две другие возможности «все еще ожидают рассмотрения».

Левин также выразил обеспокоенность по поводу соглашений об именовании, отметив, что префикс read-* в предложении противоречит шаблону get-*, принятому при выпуске Abilities API в версии 6.9. Он также задался вопросом, почему структуры API так похожи на REST API.

«У нас уже есть REST API, и ядро ​​WordPress, очевидно, обратно совместимо», — написал он. «Возможности в ядре (Core Abilities) должны представлять собой функциональные примитивы, служащие общим знаменателем для потребностей REST, CLI, палитры команд и т. д. Но на текущий момент они никак не тестировались и не анализировались».

По словам Левина, контрибьюторы на встрече AI Team 24 июня пришли к консенсусу о том, что три возможности должны пройти как минимум один полный релиз-цикл в плагине WordPress AI, прежде чем их можно будет рассматривать для включения в ядро. Он также выразил обеспокоенность по поводу отсутствия других сопровождающих Abilities API, таких как Грег Зюлковский из Automattic, перед выходом версии 7.1.

Энн Маккарти, которая руководит релизом 7.1, оспорила характеристику Левина, заявив, что на совещании контрибьюторов не принимают официальных решений, «особенно в отсутствии тех, кто работает над этим функционалом». Маккарти сказала, что для этого и существует предложение о слиянии. Левин сослался на автоматически сгенерированную стенограмму совещания и сказал, что решение отражает состояние готовности abilities и потенциал команды до выхода бета-версии 1.

В ответ на комментарии Левина Коста сказал, что работа велась не с нуля — одна из возможностей уже была в основной ветке разработки, и core/read-content основывалась на более ранних наметках, выполненных в феврале. Что касается именования, он сказал, что префикс «read» появился в ходе обсуждения того, как помочь большим языковым моделям интерпретировать имена возможностей, и что он готов рассмотреть «get», если есть основания предпочесть именно такой вариант.

Коста также добавил, что параметры, пользователи и записи — это «самые простые вещи, которые есть в WordPress», и что откладывание реализации abilities до версии 7.2 может привести к повторению тех же возражений. «Главное, что я хотел бы уточнить, это имеют ли текущие возможности какие-либо проблемы, с которыми мы не успели бы справиться до выхода бета-релиза», — написал он.

Коста заявил, что отзывы о предложении приветствуются в комментариях и в канале #core-ai в WordPress Slack.

Выпуск первой бета-версии WordPress 7.1 запланирован на 15 июля.

Источник: https://www.therepository.email

Дмитрий/ автор статьи
CCO, Senior SEM/PPC Specialist, WordPress-энтузиаст, переводчик с английского и немецкого. Серый кардинал русскоязычного WP-комьюнити.
Блог про WordPress
Добавить комментарий

Получать новые комментарии по электронной почте.