Именно из-за сложностей возникших у Gvozd, я отказался от написания подобного рода парсеров на php. php серверная технология и использовать её нужно на сервере, ИМХО.

Как насчет контроля происходящего в данный момент?

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

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

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

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

Я так считаю. Чуть копни и тут же получишь грабли. Это следует даже из ваших слов, вам нужно точить парсеры сугубо индивидуально для каждого проекта. Уровень абстракции 0.

Сколько лет вы разрабатывали свой парсер? Год, два?

Исходя из всего вышесказанного мой вердикт звучит так: технология эта топорная и должна остаться в прошлом.

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

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

напряги тут - лишние конкуренты?

micscr,
все мы друг-другу в чем-то конкуренты ;)

хорошо
и на каком же языке, можно написать парсер универсальный и сам распознающий контент на странице?
самые лучшие десктопные приложения пока что предлагают составлять проект в wysiwg-редакторе указывая интересующие нас элементы на странице, а он сам уже дальше сграбит со всех страниц указаные элементы.
есть универсальные парсеры для конкретных движков(потому что верстка типизирована), или же который выдирает основной блок контента, находя(в первом упрощении) самый большой текстовый блок не являющийся часть повторяющегося дизайна и других неконтентых элементов.
но универсального парсера, который бы разделял страницу сам на нужные вам текстовые элементы, и давал бы это в виде красивой реляционной базы - нету.ни на каких языках.
и уровня абстракции, когда я указываю основные заголовки для страницы, если они отличаются от стандартных, и набиваю с полдесятка XPath-выражений, мне вполне достаточно.
а я его почти и не разрабатываю на самом деле.
он у меня находится на уровне минимально необходимом для достаточно ыбстрого создания большинства проектов, и если мне что-то надо сделать дополнительное, обычно реализую не в самом движке, а уже в индивидуальной части проекта
и это не парсер, а движок для удобной разработки многопоточных парсеров.
буквально месяц назад мне пришлось его переписать с нуля по нескольким причинам, одна из которых то, что у меня не совсем хорошо была организована многопоточная скачка
это исключительно ваше мнение
мои парсеры верой и правдой служат моим заказчикам, и в большинстве своем они полностью довольны моей работой
опять-таки вы вбили себе факт в голову, и свято держитесь за него.
это просто святая вера. и не думаю, что мы получим пользу от холивара на этой почве.
я считаю, что PHP можно использовать для того, для чего его можно использовать.
если он может создавать десктопные клиентские приложения с графическим(не-web) Интерфейсом, то почему-бы и нет.
написание же парсеров на PHP обусловлено тем, что большинству заказчиков предпочтительней именно этот язык разработки парсера.
так исторически сложилось

Для меня такое заявления звучит очень абсурдно. Какое дело заказчикам на каком языке написан парсер?

я начинаю сомневаться в вашей адекватности
заказчики хотят:
1)запускать парсер в удобных для себя условиях. чаще всего на сервере.
под этот запрос подходит PHP,Perl
2)возможность править парсер, при необходимости.
учитывая гигантское засилье PHP-шников, в случае отсутсвие автора скрипта всегда найдется ему замена.
какая разница из свинины, конины, или вообще из сои сделана колбаса?

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

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

Вопросы адекватности меня не волнуют. Я создал эту тему с целью получить представление о мыслях других людей на данную тематику. Я их получил с лихвой. Я изначально не собирался обсуждать технологию написания парсеров на php, тут я слегка лукавлю, но не сильно. Меня даже почти заинтересовало как вы преодолели те или иные трудности. А посему так как вы не понимаете о чем я говорю, а у меня совсем нет желания объяснять, то смысл в беседе действительно отсутствует.