XML-RPC: Общие ошибки

Одна из самых часто встречающихся ошибок в реализациях XML-RPC -- экранирование лишних символов в строках. Лишних в том смысле, что спецификация XML-RPC их экранирования не требует. Для корректного парсинга пакета требуется экранировать символы: < (&lt;) и & (&amp;). Любые другие символы экранироваться не должны, но очень часто ошибочно экранируют еще и другие символы: ' (&apos;), " (&quot;), > (&gt;).

Extended RTTI {$METHODINFO ON}

Пару дней назад, налетел на очень интересную граблю. В своем XML-RPC сервере я использую возможность Delphi создавать расширенную RTTI, для регистрации объектов на сервере. Описывается класс с некоторым API, публичная часть (та, что будет доступна XML-RPC клиентам) выносится в секцию Published (для которой и создается Extended RTTI). Затем создается объект данного класса  и регистрируется на сервере. В процессе регистрации сервер получает прототипы методов разбирая RTTI. Все работает прекрасно, кроме того, что помимо методов вынесенных в Published, компилятор создает RTTI еще и для некоторых (даже перегруженных!) методов из секции Public. Грабля, вылезла на довольно сложном классе имеющем nested types. На простых классах такого не обнаруживается.

Утечка в TInterfaceList

У данного списка (как впрочем и у TList, и его потомков) есть свойство Count позволяющее, как определять количество элементов списка, так и устанавливать его. Очень удобно использовать возможность назначения количества элементов, для многократной очистки списка (т.к. делается это без перераспределения памяти к которому приводит стандартный Clear). Однако, в классе TInterfaceList данная операция приводит к потере ссылок на хранящиеся интерфейсы, следовательно они никогда не будут освобождены.

XML-RPC. Снова :)

Сегодня получил 5046 вызовов в секунду (и это на отладочной версии, со всеми проверками и ассертами)!

Delphi хотелка

Уже который раз ловлю себя на мысли, что очень хочется иметь параметризованные циклы for-in-do. Тогда можно было бы писать примерно так: For Item[Param] In Items Do... Что приводило бы к выборке значений соответствующих параметрам (разумеется, при поддержке перечислителя).

И вторая хотелка касающаяся for-in-do это наличие двух методов вызываемых перед началом перечисления и после. Что помогло бы при реализации перечислителей в виде advanced records, когда им (перечислителям) требуется выполнять некоторые операции (например блокировка/разблокировка) над контейнером.