Конкуренты или все-таки партнеры?

[nyuk]

Пока решаем с форматом экспортирования, предлагаю обсудить, какие данные экспортировать.
Вариант такой.

В корне форума лежит скрипт, с помощью которого фидошная сторона запрашивает новые сообщения. Параметром передается дата (UNIX timestamp), начиная с которой выдать посты. Например:
http://форум/fido_export.php?date=1116223972

Скрипт отдает следующие данные:

postid - идентификатор сообщения.
parentid - идентификатор сообщения, на которое отвечаем (или 0, если первое сообщение топика).
dateline - дата. Формат можно обговорить, для меня удобнее всего UNIX timestamp.
username - имя постера.
subject - сформированная строка сабж, типа " ZX-Spectrum » Железо » порт lp".
title - заголовок сообщения, может не указываться.
pagetext - сообщение.
link - прямой урл на сообщение.

Некоторые пояснения.

postid и parentid нужны для построения древовидной структуры эхи, аналогично другим фидошным эхам.
В идеале - фидошный софт на основе этих id генерирует свои 32-битные msgid, а при обратной связи, когда импорт делать будем, возвращает снова те же идентификаторы. Для того, форум знал, по каким топикам рассовывать сообщения.

dateline, username, subject - в заголовок фидошной мессаги.

title, pagetext и link объединятся в тело письма. Кто будет объеденять: форум или фидо, в принципе без разницы.

Обсудим?

[Conan]

Вариант такой.

В корне форума лежит скрипт, с помощью которого фидошная сторона запрашивает новые сообщения. Параметром передается дата (UNIX timestamp), начиная с которой выдать посты. Например:
http://форум/fido_export.php?date=1116223972

Скрипт отдает следующие данные:
subject - сформированная строка сабж, типа " ZX-Spectrum » Железо » порт lp".

Некоторые пояснения.
subject - в заголовок фидошной мессаги.

А в чем идея формировать subject такого вида на "серверной стороне"?
Верхний уровень "ZX-Spectrum" не нужен IMHO, поскольку и так subject получается "двухуровневый", да и гибкости (если что-то надо будет изменить) на клиенте больше.

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

[nyuk]

А в чем идея формировать subject такого вида на "серверной стороне"?
Верхний уровень "ZX-Spectrum" не нужен IMHO, поскольку и так subject получается "двухуровневый", да и гибкости (если что-то надо будет изменить) на клиенте больше.

Если строку сабжа формировать на клиентской стороне - гибкости больше, но и параметров передавать тоже больше.
"ZX-Spectrum" - это еще не самы верхний уровень, и он может меняться. Хотя да, вполне можно от этой строки отказаться, и так все ясно.

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

С аттачами пока ничего не смотрел, не знаю. Заменить их ссылками - это самое простое, возможно так и придется сначала сделать. А вот с разбивкой на UUE придется повозиться.

[elf/2]

Зарегился. Скачать все равно не дает. Можешь качнуть? Вроде вещь дельная.

у меня лицензии на vB нет, мне тоже не дадут

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

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

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

не недо самодеятельности ну пожалуйста
ну чем вам RSS не угодил? в любом случае на клиенте данные надо парсить. для парсинга xml уже существует огромное количество оттестированных решений, начиная с xslt и кончая xml:simlpe модулем в Perl. а для собсвенного формата надо клиенский парсер с нуля писать/тестировать

Параметром передается дата (UNIX timestamp), начиная с которой выдать посты

а зачем я про "Conditional GET" писал? ну зачем изобретать велосипед? давайте дату через "If-Modifed-Since" заголовок передавать, до кучи еще и трафик будет экономиться если изменений на форуме не было

С аттачами пока ничего не смотрел, не знаю. Заменить их ссылками - это самое простое, возможно так и придется сначала сделать. А вот с разбивкой на UUE придется повозиться.

мне тоже кажется, что надо остановиться на ссылках. если очень хочется, то на клиенте эту ссылку можно из сообщения вытащить, автоматом выкачать и заUUEncod'ить

А в чем идея формировать subject такого вида на "серверной стороне"?
Верхний уровень "ZX-Spectrum" не нужен IMHO, поскольку и так subject получается "двухуровневый", да и гибкости (если что-то надо будет изменить) на клиенте больше.

полностью согласен, пусть решение будет как можно более гибким

[nyuk]

не недо самодеятельности ну пожалуйста
ну чем вам RSS не угодил? в любом случае на клиенте данные надо парсить. для парсинга xml уже существует огромное количество оттестированных решений, начиная с xslt и кончая xml:simlpe модулем в Perl. а для собсвенного формата надо клиенский парсер с нуля писать/тестировать

Против RSS я ничего не имею. Просто, надо учитывать, что универсальный скрипт для RSS-фидера и фиды написать скорее всего не удастся. Обычная RSS-читалка смотрит только нужные ей поля, которых не так уж и много. Соответсвенно, гибкости, как написано выше уже не добиться.
Нужно писать два скрипта, точнее один, выдающий два XML: один классический RSS, другой с дополнительными полями для последующего парсинга в фидо. А если будут два варианта, то почему бы второй не сделать более удобным?

Мое мнение я уже озвучивал. Пусть фидошники решат, в каком виде им лучше получать данные.

а зачем я про "Conditional GET" писал? ну зачем изобретать велосипед? давайте дату через "If-Modifed-Since" заголовок передавать, до кучи еще и трафик будет экономиться если изменений на форуме не было

Смотрел. Детально не разбирался, только суть (вроде) ухватил. Мой вариант тоже экономит трафик и реализовать его проще. Если остановимся на RSS, тогда мой вариант не катит.

[ZS_]

Чесное слово, вы тут оба такой бред несете %) Извиняюсь, если кого обидел...
Кто-нить мне покажет структуру базы данных для этого форума?
Может вы знаете больше меня, но rss нам нафиг не нужен для гейтования. Поэтому думаю надо искать более другие варианты, а не зацикливаться на нем и xml.
Проще надо подходить к вопросу. Проще.

[Advertiser]

[nyuk]

Кто-нить мне покажет структуру базы данных для этого форума?

Прикладываю дамп свежесозданной базы. Без инсертов, их там очень много.
А вообще, astalavist.box.sk - там ищешь крякнутый движок запросом "vbulletin", куда-нить ставишь (у меня вообще локально установлен, под виндой. И вперед, смотри сколько хочешь.

Может вы знаете больше меня, но rss нам нафиг не нужен для гейтования. Поэтому думаю надо искать более другие варианты, а не зацикливаться на нем и xml.
Проще надо подходить к вопросу. Проще.

Я с самого начала говорю. Предложите! Предложите наиболее удобный вариант. Пока кроме RSS ничего предложено не было, поэтому его и обсуждаем.

[elf/2]

Кто-нить мне покажет структуру базы данных для этого форума?

какая связь между структурой базы форума и форматом экспорта?

Может вы знаете больше меня, но rss нам нафиг не нужен для гейтования. Поэтому думаю надо искать более другие варианты, а не зацикливаться на нем и xml.
Проще надо подходить к вопросу. Проще.

для гейтования нужен некий формат экспорта.
RSS is a Web content syndication format. Its name is an acronym for Really Simple Syndication.
т.е. rss это формат для обмена информацией. сам термин означает "действительно простое связывание" (перевод совсем вольный).

конечно можно придумать что-то свое, которое будет подходить для решения данной задачи. но зачем если уже есть готовое, простое и работающее решение?

[ZS_]

какая связь между структурой базы форума и форматом экспорта?

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

конечно можно придумать что-то свое, которое будет подходить для решения данной задачи. но зачем если уже есть готовое, простое и работающее решение?

НУЖНО придумать свое, а не подставляя костыли пытаться воспользоваться чем-то стандартным. Это же не Спектрумовский подход. Все равно придется разбираться с чем-то. Вот только я легко могу работать с MySQL и понятия не имею как выглядит изнутри этот rss. Зачем использовать ненужную и непроверенную прослойку библиотек для работы с rss когда можно обойтись без нее? Проще надо быть. А простота в том, что на одном конце мы имеем очень четкий формат .PKT/.MSG, а на другом таблицы MySQL. Вот и надо загонять одно в другое имея ПОЛНЫЙ набор данных, а не то что нам выдаст rss.
Я уже согласился с тем, что в код форума лезть не надо. Теперь я считаю, что конверить нужно байты в байты структура которых заранее известна.

[elf/2]

Просто, надо учитывать, что универсальный скрипт для RSS-фидера и фиды написать скорее всего не удастся. Обычная RSS-читалка смотрит только нужные ей поля, которых не так уж и много. Соответсвенно, гибкости, как написано выше уже не добиться.

ты предложил следующие поля:
postid - идентификатор сообщения.
parentid - идентификатор сообщения, на которое отвечаем (или 0, если первое сообщение топика).
dateline - дата. Формат можно обговорить, для меня удобнее всего UNIX timestamp.
username - имя постера.
subject - сформированная строка сабж, типа " ZX-Spectrum » Железо » порт lp".
title - заголовок сообщения, может не указываться.
pagetext - сообщение.
link - прямой урл на сообщение

читаем RSS 2.0 Specification (http://blogs.law.harvard.edu/tech/rss)

title - The title of the item
link - The URL of the item
description - The item synopsis
author - Email address of the author of the item
category - Includes the item in one or more categories
comments - URL of a page for comments relating to the item
enclosure - Describes a media object that is attached to the item
guid - A string that uniquely identifies the item
pubDate - Indicates when the item was published
source - The RSS channel that the item came from

т.е. имеем практически тот же самый набор полей, получается что нет никаких проблем сделать один скрипт.

при этом в стандарте rss 2.0 описана возможность расширения этого набора полей:
RSS originated in 1999, and has strived to be a simple, easy to understand format, with relatively modest goals. After it became a popular format, developers wanted to extend it using modules defined in namespaces, as specified by the W3C.

RSS 2.0 adds that capability, following a simple rule. A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.

Детально не разбирался, только суть (вроде) ухватил. Мой вариант тоже экономит трафик и реализовать его проще. Если остановимся на RSS, тогда мой вариант не катит.

а в чем разница в реализации? в твоем случае смотрим $_REQUEST['data'], в другом $_SERVER['HTTP_IF_MODIFIED_SINCE']

до кучи ссылка на php'шную реализацию "conditional GET": http://simon.incutio.com/archive/200...conditionalGet