Сегодня со свежей головой на раз два разделался с проблемой с конвертацией дат между mysql и xml-rpc, о чем я писал в предыдущем посте. Выяснил простую вещь: для передачи даты используется аж специальный класс для работы с датами. - все это в class-IXR.php. Отдаешь дату - создаешь новый экземпляр класса, получил дату - используешь функцию член класса для конвертации, а чтобы и mysql был доволен приходится это еще обрамлять двумя функциями. Получается семь одежек и все с застежками - по первому делу можно и запутаться, что со мной и произошло. Также вчера я напутал с типом даты в php - он там все таки не float, а int, то бишь unix timestamp, а float это тип даты в дельфи. Есть свои недостатки в кросязыковом программировании: иногда сложно переключаться между стилями написания исходников - у меня это между delphi и php. Строки в дельфи только с апострофами (') , а в php еще кавычки хляют ("), плюс присваивание и еще какая то мелочь. Руки уже привыкли к одному стилю в одном языке, а когда переходишь на другой начинаешь лепить ошибки в тексте.

Я полностью закончил реализацию удаленного доступа к комментариям на стороне сервера - написал и отладил класс wp_xmlrpc_comments_server, поместив его в один файл xmlrpc-comments.php. Когда напишу клиента комментариев, выложу его на всеобщее обозрение.

Сейчас приступаю к программированию на дельфи - написание клиента под Windows. Скорее всего будет одно приложение - и блог клиент и клиент для комментариев: принципиальной разницы почти никакой. Сейчас самая большая сложность для меня состоит в написании универсального модуля ListView, который бы работал как с комментариями, так и с постами. Введу в курс дела. Все посты и комментарии будут храниться в виде отдельных *.xml файлов на диске. У меня был раньше модуль, который писал и читал объект в ini файл. Но дело в том, что структура ini файла плоская: секции и пары название= значение. Для сохранения объектов, содержащих в себе другие объекты приходилось идти на ухищрения типа в название секции включал бэкслеши (). в Общем случае это моветон. Поразмыслив немного захотелось использовать xml для хранения объектов. Но с xml в стандартных библиотеках дельфи засада - он использует виндовозный xml парсер, строящий иерархию DOM. Сам по себе этот парсер медленный - для одиночных файлов подойдет, но для массового обслуживания уже начинаются серьезные тормоза. К тому же DOM - document object model мне ни к чему: после парсинга xml придется еще лазить по дереву, когда как мне надо построить объект из xml. Для сохранения объекта в xml я вообще отказался от использования вообще каких либо модулей работы с xml: пишу строки следующим образом

WriteStr(format('', [Name, TypeName, Value]));

Строки пишу в кодировке UTF-8, значения беру из RTI - run time information, модуль для работы с которой у меня был уже написан, но заточен под ini файлы. Это частный пример для простого типа, а массивы, другие объекты соораняются в дереве. Я не стал реализовывать работу со всеми возможными типами, а ограничился только простыми (строки, буквы, цифры, множества и тому подобное) и классами. А все остальное идет по боку: варианты, которые вообще никогда не использую, com интерфейсы, процедурные типы - обработчики событий. Это работает и имеет свои резоны и ограничения: объекты должны иметь нисходящую иерархию без перекрестных ссылок в published объявлении. Все мои задачи соответствуют этим требованиям, а если возникнет надобность в дополнительных фичах, то их всегда можно реализовать. Если для сохранения мне не нужен вообще какой либо инструмент для работы с xml, то для чтения xml, конечно, нужен парсер. Я искал парсер на событиях для дельфи и нашел миниатюрный работающий парсер StitchSAX 1.1 - Trivial SAX parser for Delphi Copyright (C) 2002, Roman Poterin. Юнит всего в 500 строк удовлетворил мои запросы.

Мой блог находят по следующим фразам
• как удалить плагин доступа на сайт
• где скачат бесплатно ворд 2008
• mysql не понимает правильную кодировку
• удаление плагинов
• плагин удалить
• синонимайзер
• Клиент для комментариев WordPress