Приветствую вас уважаемые коллеги. Итак, проблема следующего плана. Пишу свой OPC DA2-сервер (без ATL). Клиентов ранее не писал и с COM'ом не работал. Но в целом все понятно, кроме одного — время жизни перечислителя на стороне OPC-клиента, т.е. когда он должен сделать Release.
Поясню:
Например, OPC-клиент запрашивает перечислитель атрибутов ячеек в группе IOPCGroup::CreateEnumerator(IN REFIID riid,OUT LPUNKNOWN *ppUnk) интерфейса IEnumOPCItemAttributes. У меня два варианта релизации интерфейса:
1. Создаю класс на подобии связанного списка (с внутренними методами типа "AddItem", "GetItem", "DeleteItem" и т.д.), реализую в нем интерфейсы перечислителя, а при вызове клиентом пичкаю этот список всеми существующими ячейками в данной группе. В этом случае объект будет жить сам по себе и уже не будет зависеть от реального набора ячеек в группе. Получается таким образом я делаю некий снимок ячеек группы на момент запроса CreateEnumerator.
2. Создаю агрегатный класс для группы IOPCGroup и реализую методы интерфейса IEnumOPCItemAttributes осуществляющие навигацию уже по существующему списку ячеек в группе. В данном случае перечислитель работает с "живыми" данными и при добавлении/удалении ячеек в группе вызов Next вернет существующие ячейки.
Первый вариант дает преимущество в том, что все используемые в OPC-сервере перечислители можно реализовать одним-двумя шаблонными классами и не париться. А вот во втором случае практически каждый перечислитель надо реализовывать отдельно.
В спецификации (может от невнимательности) не нашел КОГДА должен клиент освобождать перечислитель. Подскажите, как должен вести себя сервер с перечислителями, давать информацию которая имеется на момент запроса (вариант 1) (в данном случае клиент должен получить всю необходимую информацию и освободить объект), или учитывать что клиент, получив перечислитель, может "держать его вечно" (вариант 2)? Кто писал OPC-клиенты, подскажите как вы использовали эти объекты? Есть исходники с набросками OPC-сервера где реализовал первый вариант. Но по логике склоняюсь ко второму варианту.
