Клиент википедия: Жизненный цикл клиента (Customer life-cycle) · Loginom Wiki

— Простая английская Википедия, бесплатная энциклопедия

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

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

Другой тип связанной программной архитектуры известен как одноранговая , потому что каждый хост или экземпляр приложения может одновременно действовать как клиент и как сервер (в отличие от централизованных серверов модели клиент-сервер ) и потому что у каждого одинаковые обязанности и статус.Одноранговые архитектуры часто обозначают аббревиатурой P2P .

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

Архитектура клиент-сервер и P2P сегодня широко используются.

Базовый тип программной архитектуры клиент-сервер использует только два типа хостов: клиенты и серверы. Этот тип архитектуры иногда называют двухуровневой . Двухуровневая архитектура означает, что клиент действует как один уровень, а процесс сервера действует как другой уровень.

Программная архитектура клиент-сервер стала одной из основных моделей сетевых вычислений.Многие типы приложений были написаны с использованием модели клиент-сервер . Стандартные сетевые функции, такие как обмен электронной почтой, доступ в Интернет и доступ к базе данных, основаны на модели клиент-сервер. Например, веб-браузер — это клиентская программа на компьютере пользователя, которая может получать доступ к информации на любом веб-сервере в мире.

• Всегда ждать запроса от одного из клиентов.
• Обслуживает запросы клиентов, а затем отвечает клиентам запрошенными данными.
• Сервер может связываться с другими серверами для обслуживания запроса клиента.
• Если для обработки запроса требуется дополнительная информация (или реализована защита), сервер может запросить дополнительные данные (пароли) у клиента перед обработкой запроса.
• Конечные пользователи обычно не взаимодействуют напрямую с сервером, а используют клиента.

• В большинстве случаев архитектура клиент-сервер позволяет распределить ухудшение ролей и обязанностей вычислительной системы между несколькими независимыми компьютерами, которые известны друг другу только через сеть, поэтому одним из преимуществ этой модели является большая простота обслуживания.Например, можно заменить, отремонтировать, обновить или даже переместить сервер, в то время как его клиенты остаются в неведении и не затронуты этим изменением. Эта независимость от изменений также называется инкапсуляцией .
• Все данные хранятся на серверах, которые, как правило, имеют лучший контроль безопасности, чем большинство клиентов. Серверы могут лучше контролировать доступ и ресурсы, чтобы гарантировать, что только клиенты с соответствующими разрешениями могут получать доступ и изменять данные.
• Поскольку хранилище данных централизовано, обновлять эти данные администраторам намного проще, чем это было бы возможно в архитектуре P2P. В архитектуре P2P обновления данных, возможно, потребуется распределить и применить к каждому «одноранговому узлу» в сети, что требует много времени и подвержено ошибкам, поскольку могут быть тысячи или даже миллионы одноранговых узлов.
• Уже доступно множество передовых технологий клиент-сервер , которые были разработаны для обеспечения безопасности, дружественных интерфейсов и простоты использования.
• Он работает с множеством разных клиентов разных спецификаций.

• Блокировка сетевого трафика — одна из проблем, связанных с моделью клиент-сервер .По мере увеличения количества одновременных клиентских запросов к данному серверу сервер может быть перегружен. Сравните это с сетью P2P , где ее полоса пропускания фактически увеличивается по мере добавления дополнительных узлов, поскольку общая пропускная способность сети P2P может быть приблизительно рассчитана как сумма полос пропускания каждого узла в этой сети.
• Сравнивая модель клиент-сервер с моделью Peer to Peer , в случае отказа одного сервера запросы клиентов не могут быть обслужены, но в случае сетей P2P серверы обычно распределяются между множеством узлов. Даже если один или несколько узлов выйдут из строя, например, если узлу не удалось загрузить файл, оставшиеся узлы все равно должны иметь данные, необходимые для завершения загрузки.

Клиент Википедии — Мета

См. Также : Выделенный редактор Википедии, Машинно-ориентированный интерфейс вики

Некоторые программы для чтения / редактирования на стороне клиента в настоящее время находятся в стадии разработки.

клиентов Википедии [править]

WINOR [править]

WINOR в настоящее время находится в разработке.Свяжитесь с Магнусом Манске, если хотите помочь или проверить. Больше не доступен.

WWW-Mediawiki-Client [править]

WWW-Mediawiki-Client был и продолжает разрабатываться как библиотека Perl и небольшой сценарий-оболочка, который ведет себя во многом как клиент CVS, позволяя пользователям делать обновления для загрузки контента Mediawiki и обязуясь загружать контент.

Меня не устраивает использование веб-браузера для редактирования контента. Меня не устраивает переключение между редакторами и другими приложениями для использования Википедии.Я не удовлетворен задержкой и характером извлечения ссылки «RecentChanges». Я не удовлетворен отсутствием непосредственного сотрудничества над статьями, то есть людей, работающих над одним и тем же документом, по-настоящему симулированно.

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

В частности, клиент должен

• включает (визуальный) редактор со специфическими для Википедии функциями и позволяет интегрировать альтернативные компоненты редактора
• автоматически загружает обновления RecentChanges через равные промежутки времени
• упрощает навигацию по ревизиям, например, с помощью двухпанельного окна, в котором выделяются различия.
• интегрируется с IRC-каналом Википедии
• , когда два пользователя открывают один и тот же документ с клиентом, разрешить режим совместной работы: открывается чат, и один пользователь может взять на себя управление курсором и мышью
• кэшируют статьи локально и позволяют просматривать, искать и индексировать архивы wikipedia в автономном режиме.
• делать все, что только можно придумать.

Чтобы реализовать такого зверя, сначала можно было бы взломать только существующую Википедию, используя «протокол», как определено макетом и формами HTML. Это очень неудовлетворительное решение, и в конечном итоге сервер Википедии должен научиться принимать стандартизированные XML-RPC.

Фактическая реализация может быть продвинута в несколько этапов. Сначала наиболее важным был бы простой компонент браузера / редактора: было бы неплохо иметь возможность перемещаться по Википедии и использовать ее без реального веб-браузера.Позже могут быть реализованы более продвинутые функции.

Мне лично очень хотелось бы использовать такой клиент и, возможно, было бы интересно написать его (в моем случае, вероятно, на C ++ / Qt или C / GTK). Есть ли более широкий интерес к такому инструменту?

Я начал редактор Википедии как плагин с открытым исходным кодом для Eclipse, см. Http://www.plog4u.org

Чтобы запустить такое «полное чудовище», нужно заглянуть в другие плагины, чтобы получить что-то вроде «набора плагинов для Википедии».

Например, для совместной работы этот плагин может быть интересен для начала: http://sobalipse.sourceforge.net — Axel 19:40, 7 февраля 2005 г. (UTC)

О боже, только не XML-RPC! Я согласен с тем, что нужно разбирать оглавление, дополнительные ссылки и т. д. — это плохо, но есть способы делать то, что нам нужно, через простой старый HTTP. Например, чтобы получить необработанные данные для страницы, вы можете использовать URL-адрес вида «http://www.wikipedia.org/wiki/some_article?output=raw». Также было бы неплохо получить страницу в формате HTML, но без лишних ссылок, вот так: «http: // www.wikipedia.org/wiki/some_article?output=html «. — TOGoS

Я согласен с тем, что XML-RPC (или SOAP, или WebDAV) кажется излишним. Может быть полезен простой XML , возвращающий формат для таких вещей, как недавние изменения, история и метаданные (автор, дата редакции), но простой старый HTTP должен обеспечивать всю необходимую нам семантику вызова . — Брайон ВИББЕР 01:34 11 декабря 2002 г. (UTC)

Вы правы. Мне нравится жаловаться на XML (я думаю, что XML-RPC особенно раздули), но он имеет свое место.В любом случае … Я действительно думаю, что интерфейс между сервером и клиентом должен быть как можно более простым и интуитивно понятным. Например (чтобы расширить то, что я уже сказал), чтобы обновить страницу, вы должны просто выполнить запрос PUT (или, что более вероятно, POST) на ‘http://www.wikipedia.org/wiki/article_name’ с новым сырые данные вики как тело запроса. Прямо сейчас, с помощью веб-интерфейса, вы должны отправлять данные на какой-то странный, не интуитивный URL. Я знаю, что клиент позаботится об этом (и я действительно не возражаю против этого для веб-интерфейса), но наличие простого, интуитивно понятного, не привязанного к реализации клиент-серверного интерфейса имеет ряд преимуществ. :

• делает систему более модульной
• Упростить работу разработчикам
• Мы не хотим, чтобы наши компьютеры говорили на эквиваленте английского языка, не так ли? (иди, логлан!)

Так что я думаю, что в конечном итоге стоило бы проделать небольшую дополнительную работу, чтобы заставить сервер понимать более интуитивно понятный «язык». Что это работает? Апач …? Может потребоваться небольшая работа. Но эй, это то, для чего Руби. Напишите свой собственный сервер! (Возможно, эта напыщенная речь относится к другой странице. Не стесняйтесь переместить ее, если вы так думаете.) — TOGoS

В защиту XML-RPC (SOAP) [править]

1. XML-RPC (скажем, SOAP) может показаться излишним, но я предсказываю, что использование стандартов окупится непредсказуемым образом. Вместо того, чтобы людям нужно было узнавать о нашем столь минималистичном протоколе на основе HTTP, они могут просто использовать те навыки, которые есть у SOAP сейчас.
2. Опора на стандарт дает нам возможность расти, потому что мы можем быть уверены, что у разработчиков стандартов было немного больше времени, чтобы обдумать проблемы. Было бы неловко обнаруживать, что мы постепенно расширяем наш минималистичный протокол, маленькие кусочки здесь и там, и, прежде чем мы узнаем об этом, обнаружим, что мы только что заново изобрели SOAP.
3. Сейчас (ноябрь 2003 г. ) реализации SOAP достигли такого уровня зрелости, что нам действительно не нужно выполнять дополнительную работу по синтаксическому анализу.
4. XML-RPC и SOAP имеют готовые библиотеки для всех современных языков (php, python, perl, java, C, C ++, C #, visual basic, ruby… даже javascript) и интегрированы в большие версии фреймворков (например, OpenOffice.org, Mozilla / XUL, Eclipse и т. д.). Таким образом, это ускорит чистую и быструю интеграцию многоуровневых приложений (например, даже создание клиента на основе MS-Office будет легко с помощью visualbasic / soap).
5. Это стало обычным выбором для других программ вики, открывающих свои API (по крайней мере, для phpwiki, moinmoin, jspwiki, twiki, usemod и openwiki), так что это каким-то образом привело к унификации.

Думаю, было бы неплохо получить доступ cvs к базе данных.Список сверху:

• включает (визуальный) редактор со специфическими для Википедии функциями и позволяет интегрировать альтернативные компоненты редактора

Нет пользы от использования CVS.

• автоматически получать обновления RecentChanges через равные промежутки времени

Больше не понадобится, так как cvs diff уже дает эту (и более) информацию.

• упрощает навигацию по ревизиям, например, с помощью двухпанельного окна, в котором выделяются различия.

Вы имеете в виду cvs up -D вчера -D «за 20 дней до»?

• интегрировать с IRC-каналом Википедии

Доступно множество клиентов IRC.Я не думаю, что это вообще нужно

• , когда два пользователя открывают один и тот же документ с клиентом, разрешить режим совместной работы: открывается чат, и один пользователь может взять на себя управление курсором и мышью

CVS уже решает эту проблему

• кэшируют статьи локально и позволяют просматривать, искать и индексировать архивы Википедии в автономном режиме

Это основная концепция CVS. Вы получаете рабочую копию, которая постоянно доступна вам.

И другие аргументы:

• делает систему более модульной

Я думаю, что более модульной, чем CVS, невозможно.

• Упростить работу разработчикам

Поскольку сервер поддерживает CVS, реализовывать больше нечего, все остальное уже существует.

• Мы не хотим, чтобы наши компьютеры говорили на эквиваленте английского языка, не так ли? (иди логлан!)

Я бы предпочел немецкий, но я не совсем понимаю, что вы имеете в виду…

— Бодо Тизен

Во-первых, я не совсем понимаю первый абзац. Можете ли вы подробнее остановиться на этих проблемах, которые вы видите? Например, я не понимаю, насколько плохо, что мы не можем работать над статьями «по-настоящему смоделированно».

Разве недостатки такого инструмента (в основном необходимость его загрузки — в то время как в настоящее время любой человек с веб-браузером может редактировать Википедию) не превзойдут преимущества , требующего программы для редактирования Википедии? —172. 139.98.xxx (то есть Ларри Сэнгер в поле :-))

Наличие отдельного клиента для редактирования страниц (в отличие от простого их чтения) может также послужить полезным pons asinorum для редакторов. —LDC

Вероятно, у нас может быть вариант с двойным интерфейсом: вы можете использовать свой браузер для быстрого доступа или загрузить клиент для увеличения функциональности.

Меня бы заинтересовал такой зверь. Однако насчет режима совместной работы в реальном времени я не уверен.Я не думаю, что все ладят достаточно хорошо, чтобы работать в режиме реального времени. 😉

К сведению, в веб-браузере Opera есть функция автоматической перезагрузки любой страницы через заданные промежутки времени. — Стивен Гилберт

О, еще кое-что. Вы когда-нибудь использовали библиотеку wxWindows? (http://www.wxwindows.org) Это фреймворк C ++, разработанный для кросс-платформенного программирования. Мне сказали, что он лучше работает с Win32, чем с QT или GTK. — Стивен Г.

Я бы порекомендовал написать что-нибудь, что работало бы как дополнение к Mozilla.Я подозреваю, что большая часть желаемой функциональности уже встроена или уже доступна в других плагинах. Кроме того, в наши дни это кажется самым простым способом создания платформенно-независимого программного обеспечения. —TheCunctator

Вау, спасибо за все отзывы. Во-первых, моя идея заключалась в том, чтобы никогда не заменять веб-интерфейс, а только предоставить дополнительный способ доступа к Википедии для обычных пользователей. Однако я думаю, что у клиента могут быть некоторые функции, которые не предлагает веб-интерфейс (например, совместное редактирование), которые всегда будут необязательными для использования всеми заинтересованными сторонами.

Я знаком с хорошей функцией перезагрузки Opera, но для клиента я бы, по крайней мере, в долгосрочной перспективе, представил бы что-то другое, а именно обновление, которое показывает только изменения, сделанные после последней загрузки. Это потребует дополнительных интеллектуальных возможностей клиента и сервера, но резко сократит полосу пропускания, необходимую для обновлений. Страница недавних изменений, особенно когда она очень большая, занимает сотни килобайт и регулярно перезагружается, что создает довольно значительный объем трафика.Теперь я, конечно, надеюсь, что финансовое положение Википедии хорошее, но из анализа затрат и выгод становится ясно, что деньги, сэкономленные за счет обновления с минимальным объемом занимаемой площади, легко перевесили бы время, необходимое для внедрения интеллектуального сервера и клиента.

Что касается wxWindows, да, я видел его в действии, но сам никогда не использовал. Это может быть хорошей альтернативой Qt или GTK.

Расширение Mozilla — хм, я не уверен в этом, в Mozilla нет ничего (даже компонента веб-браузера), что я бы хотел, чтобы клиент поддерживал, скорее, это будет отображать ограниченное подмножество HTML, которое Википедия использует напрямую .Это позволило бы написать небольшой комбинированный компонент браузера / редактора (каким веб-браузер должен был быть в первую очередь). — Eloq.

А, понятно. Недавние изменения действительно съедают пропускную способность; Это было источником проблем для нас в прошлом, когда приходили новые потоки трафика. w: Джимбо Уэльс мог бы рассказать вам об этом больше.

Плагин Mozilla имеет для меня большой смысл. У меня обычно есть несколько вкладок, открытых для ссылок, когда я редактирую, и компонент редактора, интегрированный с моим обычным браузером, будет намного проще в использовании, чем необходимость постоянно переключать приложения.- Арвиндн

Вы, вероятно, захотите поговорить с w: Магнусом Манске. Он главный программист для нашей новой вики-программы. Или еще лучше, если вы умеете работать с PHP и SQL, перейдите на http://wikipedia.sourceforge.net и поиграйте с кодом — Стивен Гилберт

UseModWiki RecentChanges уже поддерживает «Список новых изменений, начиная с t. ‘где t — это последний раз, когда вы загружали RecentChanges (на самом деле, это время последнего изменения, которое вы видели). Другие исправили UseModWiki, чтобы поместить это в файл cookie пользователя, а именно MoinMoin.Это не очень сложно. См. Http://www.usemod.com/cgi-bin/wiki.pl?WikiPatches/ChangesSinceLastVisit. — СунирШах

Сообщение из Intlwiki-l, сб, 7 декабря 2002 17:54:48 +0100 (CET)

Я пишу это в международный список, потому что я сомневаюсь, что английские википедисты очень заботятся об этом проблема. Сегодня я получил письмо от парня из России. кто хочет создать свою энциклопедию эсперанто проект, потому что это стоит слишком дорого, чтобы постоянно быть онлайн, чтобы поработать над энциклопедией, и он хочет распространять энциклопедию на компакт-дисках.Я также знаю что у нас НИКОГДА не будет чешской Википедии без нее потому что существует монополия на связь, которая требует, чтобы все люди (кроме очень крупных компаний) оплачивать интернет поминутно по достаточно высоким тарифам для среднего чеха.

Клиент Википедии отчаянно нужен, если мы хотим предстоит еще поработать над неанглоязычными Википедиями. Пользователи смогут получить всю энциклопедию (в какие языки они хотят) на своих жестких дисках и он может синхронизироваться, когда они подключаются к Интернет.Также такая программа ДОЛЖНА быть неанглоязычной. удобный.

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

Кто-нибудь может написать такую ​​программу?

Спасибо, Чак

просто некоторые мысли: служба электронной почты для Википедии, вы отправляете электронное письмо на определенный адрес (например, [email protected]) с темой, например:

ПОИСК Tristan Tzara

Вы получите письмо с результатами поиска.

Тогда вы пишете:

ПОЛУЧИТЕ Тристана Цара (или любое другое название статьи, которое вы хотите)

Вы вносите изменения в автономном режиме, а затем отправляете:

PUT Tristan Tzara, с вашей измененной версией в теле письма.

Если за это время никто не изменил статью, изменения применяются, иначе вы получите сообщение editconflictmail …

Для защиты этого сервиса от спамеров он может быть ограничен зарегистрированными почтовыми адресами.

Это, конечно, никогда не сработает для английской Википедии, но для небольших Википедий, особенно в такой ситуации, как чешская, это было бы возможное решение, которое не требует большого программирования (по крайней мере, я на это надеюсь — можно ли это сделать легко ?).Дополните это сжатыми HTML-версиями Википедии для загрузки и чтения в автономном режиме. —елиан

Если вы отправляете изменения не в форме новой версии, а как unidiff, большинство конфликтов будет проигнорировано. Но это уже реализовано и называется CVS, единственное, что Wikiserver должен это поддерживать. — Бодо Тизен

Бодо,

Мне нравится ваша идея «службы поиска электронной почты для Википедии». Я думаю, было бы неплохо иметь приложение для поиска для пользователей SMS, такое как SMS-служба Google.

Однако это может привести к отправке больших возвратов через SMS. Чтобы еще больше расширить эту идею, я считаю, что на каждую страницу Википедии необходимо добавить дополнительные теги, чтобы «пометить» наиболее важную информацию для возврата на мобильный телефон.

В свою очередь, поиск по SMS в Википедии будет очень похож на идею поиска по электронной почте Бодо, однако при этом будет извлечено меньше информации.

Как поиск по электронной почте в Википедии, так и поиск по SMS в настоящее время должны быть возможны без каких-либо изменений в Wikiserver.На этом сайте уже есть функция поиска. Программному обеспечению на стороне клиента нужно будет просто обрезать «данные вики». Однако для этого потребуется дополнительная связь между клиентом и Викисервером. Большая часть обработки будет перенесена на клиент, однако необходимо будет создать подключаемый модуль для Outlook. Не уверен, что это вообще возможно.

Лучше было бы выполнить подготовку к усечению и доставке на сервере.

Кэмерон

Здесь говорят о реализации «клиента», но может быть несколько.Некоторые хотят мгновенного сотрудничества, другие предпочитают работать в автономном режиме, позже объединяя свои новые вещи … Я не думаю, что реализация должна учитывать все это. Скорее опубликуйте «машинно-дружественный» спецификацию интерфейса поверх HTTP, используя специальные URL-адреса или что-то еще, и пусть люди заводят собственных клиентов. (и поделитесь ими, если они этого захотят) Я видел эту дискуссию «мне нравится C ++» / «Я использую Rebol» / «Вы проверяли wxWindows» несколько раз раньше … давай — каждому свое — нам просто нужен простой машинный интерфейс, и все начнется.Фактически, это должно быть проще (на стороне Магнуса Манске / программистов Википедии) чем удобный интерфейс.

Репост: Ой, извините, я тупой, я пропустил машинно-дружественный вики-интерфейс перед публикацией …

Кортик

Точка зрения Дирка о множественных клиентах верна. Один клиент является автономным, что может быть наиболее полезно в странах с медленным / дорогим доступом в Интернет. Такой клиент должен предоставить пользователю доступ ко всем записям или, по крайней мере, к тем, которые наиболее интересны пользователю (несколько устаревшие версии других могут быть доставлены на CD-ROM или DVD-ROM, возможно, на обложках журналов).

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

Чтобы позволить клиенту выполнять офлайн-редактирование , используйте тот же интерфейс, который использует Википедия (пользователь получает доступ к локальной Википедии с помощью своего веб-браузера), но измените код на стороне сервера, чтобы он сохранял отредактированные статьи отдельно, и может загружать их на главный вики-сервер и одновременно загружать новые версии всех статей, которые отслеживает пользователь.

— Кабаламат, 15:07, 27 августа 2003 г. (UTC)

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

Автономное редактирование будет очень важно для развивающихся стран на разных уровнях: клиенты должны иметь возможность синхронизироваться с серверами И серверы должны иметь возможность синхронизироваться с другими серверами, например. один раз в день. Таким образом можно будет создать эффективную инфраструктуру для развертывания информации.Протоколы и код уже существуют, пожалуйста, используйте их.

Если кто-то из них собирается что-то реализовать, загляните на http://www.flyingmeat.com/vpwiki.html, где это уже работает и работает хорошо. — Мартин

Модуляризация MediaWiki в сервисы [править]

Одним из недостатков текущей реализации является то, что MediaWiki не спроектирована как распределенная среда с нуля. Если мне нужно будет переписать MediaWiki, его, вероятно, следует разработать как (более или менее) независимые части, связанные с помощью веб-сервисов.Основой для этого было бы создание хотя бы элементарной структуры классов. В целом:

• Набор веб-сервисов, выполняющих все функции базы данных , поэтому будет легче переносить их на различные типы / версии баз данных. В идеале код в фоновом режиме мог бы использовать фабричные шаблоны, чтобы сделать возможной адаптацию базы данных.
• Веб-сервис для , управляющий пользователями (имя пользователя, пароль, роли пользователей и т. Д.). Поскольку это задача с высокими требованиями к безопасности, ее следует использовать только через SSL или эквивалентное шифрование.
• Веб-сервис для , конвертирующий Wikisyntax в (еще не существующий) WikiML. Это позволит (опционально) использовать разные синтаксисы, чтобы пользователь мог решить, что он более знаком. Кроме того, использование синтаксиса на основе XML позволит использовать XSLT для форматирования вывода.
• Веб-сервис , запрашивающий изменения в базе данных. Это позволит пользователю определить, устарела ли кешированная версия статьи. Этот метод также может позволить разработать своего рода распределенную MediaWiki, где у пользователей есть вики-клиент, который запрашивает изменения в статьях.Если их нет, будет использоваться кешированная версия в клиенте. В противном случае вместо всех данных будет использоваться только (набор) diffgramm (s). Этот метод может сэкономить полосу пропускания и вычислительную мощность.
  

В случае накладных расходов на веб-службы я не вижу никаких проблем, потому что для внутренних классов MediaWiki все еще можно будет напрямую вызывать соответствующие функции. Веб-службы будут реализованы как оболочки.
Самые большие проблемы, которые я вижу, — это выбранный язык PHP.Поскольку этот язык сценариев изначально не создавался для больших сред или веб-сервисов, у него есть некоторые недостатки:

• Он будет работать медленнее, чем скомпилированный код
• Внедрение веб-сервисов будет сложнее. Веб-сервисы проще в таких средах, как ASP.Net, ведьма была создана с помощью веб-сервисов в уме. Поэтому я рекомендую разрешить использование Mono и Java, если у общедоступных функций есть SOAP-Wrappers.
  

Таким образом, преимущества сервис-ориентированной архитектуры заключаются в следующем:

• Легко расширить новыми Услугами на основе существующих.Примерами таких сервисов являются Specialpages.
• Для новых функций могут потребоваться новые интерфейсы. Но расширение частей приложения не повлияет на существующие службы.
• Более простое распространение за счет зеркалирования только отдельных Сервисов на разных Серверах, а не целого. Т.е. Обработка пользователей может выполняться на одном компьютере, а не отражаться вместе с остальной частью Википедии. Другим примером могут быть общие ресурсы, ведьма могут работать на другом кластере, ведьма, в свою очередь, специализируется на статическом контенте.

MovGP0 00:31, 23 февраля 2006 г. (UTC)

Первые попытки в wkp-режиме для просмотра Википедии из Emacs [править]

См. Мою страницу пользователя Пользователь: MwZurp. По-прежнему только просмотр, но хотелось бы перейти к редактированию.

Повторно используйте то, что предлагает ОС [править]

1. XULrunner (новый продукт Mozilla) 2. FCKreator как база для инструментов редактирования. 3. Расширение Chatzilla для совместной работы с ICR

Если Mozilla Crue вовремя внедрит SVG, следующий уровень представления данных будет достигнут.Выбор этого подхода даст нам мощный движок рендеринга и платформу Croos.

Изменение существующих браузеров? [Править]

Что, если вместо того, чтобы создавать собственное клиентское программное обеспечение с нуля, мы модифицируем (расширяем, добавляя настраиваемые функции) существующие веб-браузеры (например, Firefox через расширения) и делаем их полноценными клиентами Википедии? 61.94.149.55 03:23, 26 мая 2005 г. (UTC)

Например, посмотрите, что сделал w: flock (веб-браузер) с интеграцией нескольких служб блогов и клиентов в браузер.Любой вики-клиент, интегрированный в браузер, должен быть простым местом для ввода текста с кнопками для всех типичных функций. Однако сначала кнопки не были определены вообще — вы могли бы выбрать, скажем, из выпадающего меню, вики, которую вы использовали (wikipedia? Pm wiki? Pb wiki? И т. Д.), И кнопки переключились бы на этот набор конкретных выходных данных, чтобы убедиться, что все операторы шрифтов и т. д. работают в любой вики-системе. Вы даже можете позволить пользователям программировать свои собственные кнопки и т. Д. Возможны всевозможные макросы и тому подобное.Было бы неплохо … намного лучше, чем эти маленькие страницы редактирования вики, и все же в духе интеграции нескольких функций в одну область и сделать ее доступной для непрофессионала. — Предыдущий комментарий без знака был добавлен пользователем 70.116.16.157 (обсуждение • вклад) 2009-03-04T10: 30: 21 (UTC)

Доступ через WebServices [править]

Давным-давно была дискуссия о внедрении WebServices с использованием NuSOAP. Кто-нибудь работает над этим? Я хотел бы стать волонтером для этого.Доступ к Wiki через альтернативный механизм (такой как SOAP, XML-RPC или даже ATOM, RSS) может быть очень полезен, особенно для портативных устройств с ограниченными возможностями отображения. На такие устройства можно установить совместимый вики-клиент, и пользователь может установить предпочтения относительно того, как должна быть размещена информация (статья, изображение и т. Д.). Хорошо документированный уровень веб-служб может использоваться клиентом на базе рабочего стола, который предоставляет расширенные функции, такие как редактирование, корректура статей и т. Д. — AG

Взгляните на http: // meta.wikimedia.org/w/query.php. —Hartz 18:58, 5 сентября 2006 г. (UTC)

CXuesong / WikiClientLibrary: / * 🌻 * / Клиентская библиотека Wiki — это портативная и асинхронная клиентская библиотека MediaWiki API на платформе .NET Standard.

Созданная вручную асинхронная клиентская библиотека MediaWiki API для вики-сайтов (включая Wikipedia и родственные ей проекты, а также FANDOM и Wikia.org. Библиотека ориентирована на .NET Standard 2.1 и .NET 5.0 (см. Поддерживаемые платформы) и ориентирована на о совместимости API с MediaWiki 1.19 (Wikia), а также современные API-интерфейсы MediaWiki (например, 1.34-wmf, как в 2019-05). Остальные промежуточные версии, надеюсь, также совместимы.

Если вы используете предыдущие версии .NET Core или .NET Framework, вы можете использовать предыдущую версию пакетов WCL. Библиотеки WCL v0.7.x нацелены на .NET Standard 1.1 и должны поддерживать более ранние версии реализаций .NET.

Пакеты CXuesong.MW.WikiClientLibrary. * теперь доступны в NuGet. Например. вы можете установить основной пакет, используя следующую команду

 # Консоль управления пакетами
Установочный пакет CXuesong.MW.WikiClientLibrary
# .NET CLI
dotnet добавить пакет CXuesong.MW.WikiClientLibrary 

Если вы столкнетесь с ошибками, у вас есть предложения или пожелания, не стесняйтесь открывать вопрос. Также приветствуются любые вклады в документацию (аннотации кода и вики-репозиторий). Спасибо.

См. Также

Обзор

Разработанный в Visual Studio 2019, этот переносимый и асинхронный клиент API MediaWiki обеспечивает простой и асинхронный доступ к часто используемому API MediaWiki.Библиотека имеет следующие особенности

• Запросы и редактирование страниц, категорий и файлов; просмотр информации о странице; загрузка файлов.

• Вход / выход с помощью простых асинхронных функций.

  • Код клиента имеет доступ к CookieContainer и, следовательно, имеет шанс сохранить его.

• токенов инкапсулированы в функции библиотеки, поэтому клиенту не нужно будет возвращать их снова и снова.

• Продолжение запросов инкапсулируется в IAsyncEnumerable , что облегчит боль при использовании генераторов страниц.

• Прочие разные API MediaWiki, например

  • OpenSearch
  • Разбор страницы
  • Патруль

• Консоль Scribunto Lua и поддержка выполнения серверных модулей

• Поддержка структурированных дискуссий (также известного как Flow)

• Базовая поддержка API Wikibase (серверная часть Викиданных); библиотека предоставляет возможность использовать дамп Wikibase JSON

• Базовая поддержка FANDOM / Wikia API (Nirvana, Wikia AJAX и Wikia REST-ful API v1)

Клиент | Лига легенд вики

Клиент игры

Клиент League of Legends — это программа, с помощью которой игроки взаимодействуют с League of Legends и Teamfight Tactics (ПК), не играя в игру.Игроки входят в клиент, используя свою учетную запись Riot , и имеют возможность оставаться в системе.

Организация

У клиента есть три раздела, которые всегда видны. Они исчезают один раз при выборе чемпиона.

Панель навигации

В верхней части навигации показаны кнопки для навигации по клиенту.

Социальное меню

В боковом меню отображается связь.

Смотровое окно

Окно, в котором отображается содержимое.

Вкладки

На панели навигации отображается пара вкладок, охватывающих все содержимое.

Играть

Это меню показывает доступные очереди для начала подбора игроков в игре.

Дом

Вкладка «Главная» становится страницей по умолчанию при входе в систему. Есть несколько разделов общего значения, а также новые разделы, которые добавляются для отображения событий и выпусков.

• Обзор
  • Показывает последние новости и продажи.
• Новости
  • Показывает новостные публикации с leagueoflegends.com
Описание обновления
• • Показывает копию последних примечаний к патчу с возможностью публикации в социальных сетях.

TFT

Вкладка TFT отображает проход события, а также новые выпуски.

Столкновение

Вкладка Clash — это интерфейс для организации матчей Clash.

• Концентратор
  • Отображает запланированные турниры, а также историю.
• Найди команду
  • Отображает функцию, позволяющую свободным агентам находить команды, к которым они могут присоединиться.
• Кронштейн
  • Отображает текущую информацию о скобках.
• Победителей
  • Показывает победителей предыдущих турниров.
• Награды
  • Перечисляет полученные награды, которые могут применяться к Clash, например логотипы и баннеры.

Коллекция

На вкладке «Коллекция» отображаются ресурсы до начала игры и персонализации.См. Статью о конкретных функциях.

Ремесло

Вкладка Крафт используется для сортировки и преобразования добычи в постоянные предметы для персонализации. Чемпионов также можно получить через эту систему.

Ваш магазин

Иногда для покупки становятся доступны персонализированные предложения скинов со скидкой.

Магазин

На вкладке «Магазин» представлены предложения по микротранзакциям, в том числе скины, билеты на конфликты и серверные передачи.

Валюта

Количество валюты игрока включает синюю эссенцию и RP. Также показаны любые льготы.

Окно чата

В окне чата отображаются последние сообщения от друзей. Окно можно отделить как отдельную программу.

Задания

В окне миссий отображаются цели, за выполнение которых предлагаются награды.

Голосовой чат

Голосовой чат доступен в группе и переносится в игру.

Отчет об ошибке

Отчет об ошибке можно отправить через Интернет.

Примечательные особенности

Параметры в игре

Внутриигровые параметры, такие как привязки горячих клавиш и ползунки звука, доступны в меню параметров.

Отдельное окно чата

Окно чата можно отключить как отдельную программу.

История

Клиент заменяет клиент PVP.net, который изначально был выпущен вместе с игрой, с целью заменить его с точки зрения технологий и визуальных эффектов, а также создать масштабируемую платформу для создания функций на долгие годы.С тех пор клиент получил известность из-за множества проблем с производительностью, которые преследовали почти все аспекты клиента, что особенно ощущалось на старых машинах, для которых игра была разработана.

В 2020 году кампания по «исправлению клиента» начала решать различные всеобъемлющие проблемы в обычных функциях клиента, в основном за счет повторной консолидации программы, чтобы она работала более эффективно и, следовательно, намного быстрее.

Медиа

Коррупция в Викиленде? Платный пиар-скандал разразился в Википедии

Обеспокоенные википедисты подняли тревогу в понедельник, что два доверенных лица — один из них — попечитель Фонда Викимедиа в Великобритании, другой — уважаемый википедист в резиденции — якобы редактируют страницы Википедии и способствуют размещению на первых страницах своих рекламных материалов. клиенты, стремящиеся к гласности.

Джимми Уэльс недоволен.

Все началось на этой неделе, когда на странице обсуждения DYK («Знаете ли вы») началась интересная дискуссия.

Роджер Бамкин, попечитель Фонда Викимедиа в Великобритании, чья страница в LinkedIn описывает его как высокопоставленного консультанта по связям с общественностью, похоже, использовал функцию «Знаете ли вы» главную страницу Википедии и ресурсы GLAM WikiProject (Галереи, библиотеки, Архивы и музеи), чтобы развлечь проект своего клиента.

Текущий клиент Бамкина — страна Гибралтар.

В августе о Гибралтаре на главной странице Wikipedia DYK показывали целых семнадцать раз — необычная частота — каждые 2-3 дня.

Помимо Олимпийских игр, это единственная повторяющаяся тема в течение месяца.

В разделе «Знаете ли вы» на главной странице Википедии публикуются новые или расширенные статьи — аудитория на главной странице Википедии оценивается в сотни миллионов в месяц.

Уэльс: «совершенно неприемлемо»

Когда основателю Википедии рассказали о клиенте Бамкина в связи с Wikimedia UK, Джимми Уэйлс написал:

Совершенно неприемлемо для члена правления отделения или любого другого лица, занимающего официальную роль в благотворительной организации, связанной с Википедией, принимать платежи от клиентов в обмен на обеспечение благоприятного размещения на первой странице Википедии или где-либо еще. еще. — Джимбо Уэльс (разговор) 00:54, 17 сентября 2012 г. (UTC)

В то же время, когда консультационная работа Бамкина в качестве представителя Фонда Викимедиа подняла свою уродливую голову, члены сообщества Википедии разоблачили SEO-ориентированную PR-стратегию редактирования страниц Википедии, которой руководит уважаемый редактор GLAM Макс Кляйн.

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

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

Максимиллион Кляйн управляет консалтинговым бизнесом под названием «untrikiwiki», само описание которого объясняет:

Положительная статья в Википедии неоценима для SEO: она почти гарантированно попадет в тройку лучших Google.Удивительно, но это преимущество написания статей для Википедии используется недостаточно, но оно точно связано с отсутствием настоящего опыта в этой области. … У НАС НЕОБХОДИМА ЭКСПЕРТИЗА, чтобы ориентироваться в сложном лабиринте, окружающем редактирование «конфликта интересов» в Википедии. Обладая более чем восьмилетним опытом, более 10 000 правок и бесчисленными связями с сообществом, мы предлагаем комплексные услуги Википедии.

Я не знал об этом деле, и у меня не было времени разобраться в нем.Если то, что вы говорите, верно, то, конечно, я очень недоволен этим. Это отвратительно. — Джимбо Уэльс (разговор) 00:54, 17 сентября 2012 г.

Нет конкретной политики Викимедиа в Великобритании в отношении «платного редактирования»

В настоящее время не существует политики Викимедиа Великобритании против «платного редактирования» страниц Википедии, хотя Джимми Уэльс сказал, что платное редактирование противоречит ценностям и политике Википедии.

Однако нет никаких сомнений в том, что отсутствие четкой политики бросает тень на восприятие общественностью этического статуса Википедии.

Если PR-редактирование представителей Википедии — платное или нет — будет открыто терпимо, репутации Википедии наверняка будет нанесен ущерб, отличный от вреда, нанесенного вандализмом или скрытым PR-редактированием.

В случае с Роджером Бамкиным, директор Wikimedia UK рекламирует себя как директора Wikimedia UK для оплачиваемых консультационных работ, а также руководит и участвует в редактировании Википедии для обслуживания своего личного клиента.

На странице Бамкина в LinkedIn указано:

Опыт Роджера Бамкина

Консультант Victuallers Ltd Май 2012 г. — настоящее время (5 месяцев)

Я работал с QRpedia и Monmouthpedia, которые принесли более 2 млн фунтов стерлингов на инвестиции в размере 50 000 фунтов стерлингов.

В официальной Декларации интересов Бамкина для Wikimedia UK говорится, что у него нет конфликта интересов (COI) с его ролью, доступом к ресурсам Википедии и контрактом с Гибралтаром, так как между Гибралтаром и Wikimedia UK нет официальных отношений.

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

Вам может быть интересно, как страна Гибралтар оказалась в центре скандала, связанного с редактированием PR Википедии.Чтобы ответить на этот вопрос, мы можем посетить Википедию.

Monmouthpedia — это проект Википедии, который связывает Википедию и город Монмут в Южном Уэльсе с помощью QR-кодов, сканируемых смартфоном.

Как гласит история, идея Monmouthpedia возникла, когда Роджер Бамкин и Стив Вирджин (бывший член правления Wikimedia UK, нынешний консультант по связям с общественностью и деловой партнер Бамкина) выступили на TEDx о своем проекте QR-кода в Википедии QRpedia. Из зала редактор Википедии Стив Каммингс (также деловой партнер Бамкина) предложил им «сделать целый город».»

Wales Online писал:

Он [Бамкин] выбрал Гибралтар, на южной оконечности Испании, в качестве своего следующего проекта после того, как его засыпали приглашениями из разных уголков мира, надеясь стать вторым городом в Википедии.

Войдите в Гибралтарпедию. Вчера BBC News объяснили, что Гибралтарпедия — это то, как Гибралтар использует QR-коды и Википедию для нацеливания и привлечения туристов.

Хотя гибралпедия не так проста, как открытое предложение Untrikiwiki по навигации по сложным правилам конфликта интересов в Википедии в качестве услуги для платежеспособных клиентов, она может быть отличной идеей, но все же представляет собой не более чем бесплатную рекламу для туризма — создание огороженного сада все статьи посвящены развитию туризма — и потенциальных инвестиций — в Гибралтаре.

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

Из заявления Джимми Уэльса за 2009 год:

Меня не устраивает, что кто-либо когда-либо создавал сервис, продающий свои услуги в качестве редактора Википедии, администратора, бюрократа и т. Д. Я лично заблокирую любые дела, которые мне покажут. (…)

(…) Заблокируем ли мы хорошего редактора, если узнаем постфактум, это совсем другой вопрос.У нас есть традиции прощения и работы с людьми, чтобы улучшить их и наше поведение, когда это возможно — никогда не бывает так просто. Конечно, можно представить себе ситуацию, когда кого-то можно и нужно простить … потому что это очень часто.

Это не то же самое, что сказать, что это когда-либо будет нормально, с точки зрения политики. Представьте себе катастрофу для нашей репутации.

Я думаю, многие люди сочли бы, что идея «Знаете ли вы» — и первая страница Википедии — успешно используется в коммерческом предприятии какой-либо организацией, как вредная для Википедии, репутации или чего-либо еще.

Но опять же, Википедия и предполагаемые конфликты интересов, как известно, не решаются с практичностью или ясностью. Просто спросите Филипа Рота.

Заказчик по проектированию и строительству

Кодекс практики управления проектами CIOB 4-е издание определяет клиента как «юридическое лицо, физическое или юридическое лицо, которое прямо или косвенно вводит в эксплуатацию и финансирует проект».

Клиент также иногда упоминается как:

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

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

Важно, чтобы распределение обязанностей между членами команды клиента было четко определено.

Для небольших или менее сложных проектов некоторые роли могут быть объединены. Однако в государственных проектах не рекомендуется совмещать роли лица, принимающего инвестиционные решения, старшего ответственного владельца и спонсора проекта из-за риска конфликта интересов.Нельзя совмещать роли, которые не пересекаются.

По проектам в государственном секторе руководство OGC показывает отношения между клиентом и командой интегрированных поставщиков (проектировщики, поставщики, подрядчики), как показано ниже [изображение воспроизведено с разрешения OGC].

NB: Управление государственной торговли (OGC) было включено в Группу эффективности и реформ (ERG) в составе Кабинета министров, и его руководство заархивировано, однако большая часть той же терминологии и процедур все еще используется в закупках в государственном секторе.

Чемпионы клиентов могут быть идентифицированы и наделены правом собственности на определенные компоненты проекта. Это может быть защитник видения, управления изменениями, коммуникаций и так далее. Этим чемпионам может потребоваться вклад и помощь многих других людей в организации-клиенте. Для поощрения этого вклада жизненно важно, чтобы люди понимали важность проекта и его потенциальное влияние на их будущее.

Для многих из участников проект будет «параллельной деятельностью», выполняемой в дополнение к их повседневной работе.Это означает, что их индивидуальные цели должны быть согласованы, чтобы включить цели проекта, а вознаграждение для людей должно исходить из успеха проекта, а не просто быть привязанным к их обычной повседневной работе. Из-за этой дополнительной роли им может потребоваться дополнительная поддержка и руководство, чтобы помочь им сосредоточиться на ключевых вопросах и максимально использовать свое время.

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

Правила CDM определяют «домашних клиентов» как «… людей, у которых есть строительные работы, проводимые в их собственном доме или доме члена семьи, которые не выполняются в рамках бизнеса, независимо от того, ради прибыли они или нет. ‘

NRM1: Порядок оценки затрат и планирования затрат на капитальные строительные работы, дает следующее определение работодателя; «… Собственник и / или застройщик здания; в некоторых случаях конечный пользователь. Термины старший ответственный владелец (СРО) и спонсор проекта используются центральным гражданским правительством и оборонным сектором; быть представителями, уполномоченными управлять строительным проектом и принимать конкретные решения по проекту.’

Интеллектуальный клиент — это клиент, который «… имеет опыт и необходимые знания для разработки, разработки и реализации строительного проекта с оптимальным сочетанием времени, стоимости и качества». Ссылка Руководство для государственных заказчиков по закупкам строительных работ, опубликованное Управлением по закупкам и собственности Шотландии 21 декабря 2018 г.

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

Старший ответственный владелец — Designing Buildings Wiki

В проектах, финансируемых государством, старший ответственный владелец (SRO) (иногда именуемый «владельцем проекта»):

«… человек, ответственный за успех проекта …»

(см. Руководство по достижению совершенства 2 — Организация проекта)

‘… отвечает за обеспечение того, чтобы программа изменений или проект соответствовали своим целям и приносили прогнозируемые выгоды.СРО должна быть владельцем общего бизнес-изменения, которое поддерживается проектом, и должна гарантировать, что изменение сохраняет свою бизнес-направленность, имеет четкие полномочия и что контекст, включая риски, активно управляется. Этот человек должен быть руководителем и должен нести личную ответственность за успешное выполнение проекта. Они должны быть признаны собственниками во всей организации ».

(см. Обзор процесса шлюза OGC 1: Обоснование бизнеса.)

Старший ответственный владелец владеет проектом на высшем уровне (эквивалентно директору совета директоров, ответственному за проект в частном секторе).Их обязанности носят скорее стратегический, чем повседневный характер.

Обязанности старшего ответственного владельца :

• Быть лидером в дизайне проекта с личным обязательством создать объект, демонстрирующий превосходное качество дизайна, или гарантировать, что соответствующий человек возьмет на себя ответственность лидера дизайна.
• Для наблюдения за подготовкой бизнес-обоснования и бюджета проекта, обеспечения реалистичности предложений и соответствия бизнес-целям, а также представления их лицу, принимающему инвестиционные решения IDM, на утверждение.
• Установить соответствующую организационную структуру и необходимые коммуникационные процессы, чтобы гарантировать, что пользователи и другие заинтересованные стороны вовлечены в проект и привержены ему.
• Назначить спонсора проекта и предоставить техническое задание, адекватные ресурсы и любую необходимую поддержку и обучение для обеспечения разработки краткого описания, четко отражающего цели проекта и согласованного с заинтересованными сторонами.
• Установить порядок выполнения и отчетности, гарантируя, что любые изменения в обстоятельствах, влияющих на проект, оцениваются и принимаются соответствующие меры.
• Для решения проблем с членами команды клиента и другими заинтересованными сторонами.
• Утвердить любые существенные изменения в объеме проекта, гарантируя, что любое влияние на качество, стоимость или время оценивается и сообщается высшему руководству по мере необходимости.
• Для обеспечения того, чтобы проверка после внедрения (также известная как оценка занятости постов) была проведена и рассмотрена всеми заинтересованными сторонами в проекте.
• Чтобы гарантировать, что готовый актив по-прежнему поддерживает и удовлетворяет бизнес-целям, чтобы гарантировать, что бизнес принимает и извлекает выгоду из готового актива.
• СРО ( старший ответственный владелец ) должна составить условия назначения спонсора проекта, указав следующее:

1. бизнес должен быть решен в рамках проекта
2. ресурсы, доступные спонсору проекта, внутренние и внешние
3. полномочия, предоставленные спонсору проекта для принятия решений
4. Обязанности спонсора проекта в отношении правил охраны труда и техники безопасности (см. AE10: Здоровье и безопасность).

(см. Руководство OGC по достижению совершенства 2 — Организация проекта.)

Дополнительные роли, относящиеся к закупке строительных работ, см. В разделе «Строительные проекты OGC: контрольный список для менеджера».

Отношения между старшим ответственным владельцем и остальной частью проектной группы проиллюстрированы в руководстве OGC, как показано ниже:

Иллюстрация воспроизведена с разрешения OGC (см. Руководство OGC 2: Организация проекта: роли и обязанности.)

Проверки шлюза инициируются старшим ответственным владельцем , и они несут ответственность за отчеты об обзоре и любые рекомендуемые меры по исправлению положения (дополнительную информацию см. В статье о OGC).

NB: Управление государственной торговли (OGC) теперь включено в Группу эффективности и реформ (ERG) в аппарате Кабинета министров. Руководство OGC было заархивировано.

Зеленая книга, Руководство центрального правительства по оценке и оценке, опубликованная Казначейством Ее Величества в 2020 году, предлагает старшему ответственному владельцу: «… человек, которому подчиняется руководитель проекта или программы, он« владеет »предложением от имени исходная организация, но не участвует в ее повседневной работе.Они несут общую ответственность за то, чтобы задавать вопросы, следить за их ходом, решать важные внешние проблемы и принимать стратегические решения о том, подавать ли на утверждение или нет ».