Лучший способ сделать межпроцессное взаимодействие на Mac OS X

Question

Лучший способ сделать межпроцессное взаимодействие на Mac OS X

Описанная вами ошибка - это именно то, что RequireJS дает вам, когда у вас есть вызов require в форме CommonJS (require('modX')) вместо формы AMD (require(['modX'], function (modX) {...})), и вызов выполняется без обертывания define. RequireJS предоставляет некоторую поддержку для использования формы CommonJS, но разработчик должен выполнить минимум работы, чтобы убедиться, что он работает. Сценарий, начинающийся с этого, не будет работать:

var modX = require('modX');
// rest of the module

Получено сообщение об ошибке. Вам нужно это вместо этого:

define(function (require) {
    var modX = require('modX');
    // rest of the module
});

Что происходит с вашей настройкой, так это то, что Babel преобразует модули ES6 в то, что использует require без оболочки define. Чтобы заставить Babel выводить надлежащие модули AMD, вам необходимо установить babel-plugin-transform-es2015-modules-amd и добавить transform-es2015-modules-amd в свой список плагинов Babel. См. Документацию здесь .

26

rbenv

задан Georg Fritzsche 17 May 2010 в 03:15

3 ответа

Мы используем ThoMoNetworking , он отлично работает и быстро настраивается. В основном это позволяет отправлять объекты, совместимые с NSCoding, в локальной сети, но, конечно, также работает, если клиент и сервер находятся на одной машине. Как оболочка для базовых классов, она заботится о сопряжении, пересоединениях и т. Д.

6

ответ дан NSSplendid 28 November 2019 в 07:40

Отказ от ответственности: Распределенные объекты недоступны на iPhone .

Почему вы находите распределенные объекты неэлегантными? Здесь они звучат как хорошее совпадение:

прозрачный маршаллинг фундаментальных типов и классов Objective-C
на самом деле не имеет значения, являются ли клиенты локальными или удаленными
, не так много дополнительной работы для приложений на основе Какао

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

13

ответ дан 28 November 2019 в 07:40

Другие вопросы по тегам:

rbenv

Похожие вопросы:

score 15 · Accepted Answer

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

О вариантах, которые вы рассмотрели:

Управляющие файлы: Хотя можно общаться через управляющие файлы, вы должны помнить, что файлы должны передаваться через сетевую файловую систему между машинами. Таким образом, сетевая файловая система служит абстракцией реальной сетевой инфраструктуры, но не предлагает всей мощности и гибкости, которыми обычно обладает сеть. Реализация: Практически, для каждой пары клиент/сервер необходимо иметь как минимум два файла: файл, который сервер использует для отправки запроса клиенту(ам), и файл для ответов. Если каждый процесс может обмениваться данными в обе стороны, вам необходимо продублировать это. Более того, и клиент(ы), и сервер(ы) работают по принципу "pull", т.е. им нужно часто обращаться к управляющим файлам и проверять, не появилось ли что-то новое.

Преимущество этого решения в том, что оно сводит к минимуму необходимость изучения новых техник. Большим недостатком является то, что оно предъявляет огромные требования к логике программы; о многих вещах нужно позаботиться самостоятельно (Будут ли файлы записаны целыми или может случиться так, что какая-либо сторона заберет несовместимые файлы? Как часто должны выполняться проверки? Нужно ли мне беспокоиться о файловой системе, например, о кэшировании и т.д.? Могу ли я добавить шифрование позже, не возиться с вещами вне моего программного кода? ...)

Если бы переносимость была проблемой (а это, насколько я понял из вашего вопроса, не так), то это решение было бы легко перенести на разные системы и даже на разные языки программирования. Однако я не знаю ни одной системы сетевых файлов для iPhone OS, но я не знаком с этим.
Сокеты: Интерфейс программирования, конечно, отличается; в зависимости от вашего опыта программирования сокетов это может означать, что вам придется больше работать, сначала изучая его, а потом отлаживая. Implementation: Практически, вам понадобится аналогичная логика, как и раньше, т.е. клиент(ы) и сервер(ы), общающиеся по сети. Несомненным плюсом такого подхода является то, что процессы могут работать по принципу "push", т.е. они могут слушать сокет до тех пор, пока не придет сообщение, что превосходит регулярную проверку управляющих файлов. Сетевые повреждения и несогласованности также не являются вашей заботой. Более того, у вас (возможно) будет больше контроля над тем, как устанавливаются соединения, а не полагаться на то, что не контролируется вашей программой (опять же, это важно, если вы решите позже добавить шифрование).

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

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

[EDIT: В частности, как только вы передаете двоичные числа, эндианальность становится проблемой, и вам приходится решать эту проблему вручную - это обычный (!) частный случай проблемы "правильной информации", о которой я говорил выше. Это может подкосить вас, например, когда PowerPC общается с Intel Mac. Этот особый случай исчезает с решением 3.+4. вместе со всеми остальными проблемами "правильной информации".]
+4. Распределенные объекты: Кластер класса NSProxy используется для реализации распределенных объектов. NSConnection отвечает за установку удаленных соединений как необходимое условие для передачи информации, так что как только вы поймете, как использовать эту систему, вы поймете и распределенные объекты. ;^)

Идея заключается в том, что ваша высокоуровневая логика программы не требует изменений (т.е. ваши объекты общаются через сообщения и получают результаты, и сообщения вместе с возвращаемыми типами идентичны тем, к которым вы привыкли в вашей локальной реализации), без необходимости беспокоиться о специфике сетевой инфраструктуры. По крайней мере, в теории. Реализация: Я также работаю над этим прямо сейчас, поэтому мое понимание все еще ограничено. Насколько я понимаю, вам нужно создать определенную структуру, т.е. вы должны решить, какие процессы (локальные и/или удаленные) могут получать сообщения; этим занимается NSConnection. На этом этапе вы неявно определяете архитектуру клиент/сервер, но вам не нужно беспокоиться о проблемах, упомянутых в пункте 2.

На сервере проекта Gnustep есть введение с двумя наглядными примерами; оно иллюстрирует, как работает технология, и является хорошей отправной точкой для экспериментов: http://www.gnustep.org/resources/documentation/Developer/Base/ProgrammingManual/manual_7.html

К сожалению, недостатками являются полная потеря совместимости (хотя при упомянутой вами настройке - только Mac и iPhone/iPad - вы справитесь) с другими системами и потеря переносимости на другие языки. Gnustep с Objective-C в лучшем случае совместим по коду, но нет способа взаимодействия между Gnustep и Cocoa, см. мою правку к вопросу №2 здесь: CORBA на Mac OS X (Cocoa)

[EDIT: Я только что наткнулся на еще одну информацию, о которой я не знал. Хотя я проверил, что NSProxy доступен на iPhone, я не проверил, доступны ли другие части механизма распределенных объектов. Согласно этой ссылке: http://www.cocoabuilder.com/archive/cocoa/224358-big-picture-relationships-between-nsconnection-nsinputstream-nsoutputstream-etc.html (ищите страницу по фразе "iPhone OS") их нет. Это исключает данное решение, если вы требуете использовать iPhone/iPad в данный момент.]

Итак, в заключение следует отметить, что существует компромисс между усилиями по изучению (и внедрению и отладке) новых технологий с одной стороны и ручным кодированием низкоуровневой коммуникационной логики с другой. Хотя подход распределенных объектов берет на свои плечи наибольшую нагрузку и влечет за собой наименьшие изменения в логике программы, его труднее всего изучить, а также (к сожалению) он наименее переносимый.