Будем делать из лора чатик?

лучше гейт для жаббера

и робота для gwave

SOAP - это монструозное уг.

вот если будет SOAP гейт очень просто будет сделать :)

> SOAP - это монструозное уг.

вы их просто готовить не умеете (ц)

если SOAP не использовать для передачи мегабайт данных (для чего он не предназначен), то он работает очень неплохо. описанные функции будут передавать небольшие порции информации. представь себе XML'ку в которой передается даже тысяча ID'шников (большой LOR'овский тред). оверхед где-то 3-4. ID-шник где-то 7 символов - 7000*4 = 28000 байт. фигня.

сейчас один релоад темы про DebSRC (>= 400 постов) почти 1 мегабайт занимает.

а так у нас уже есть tkLor, есть гейт Lor-News, на подходе гейт Lor-Email: всем жизнь резко упростится. кто-то сможет сделать гейт LOR-jabber :)

> всем жизнь резко упростится. кто-то сможет сделать гейт LOR-jabber :)
Но ему придется доверить свой логин и пароль от Лора. Можно как-то это сделать, чтоб было на том же сервере, что и сам Лор, а не на каком-то стороннем? Свой собственный могут поднять не все, не у всех интернет достаточно хорош.

> Свой собственный могут поднять не все, не у всех интернет достаточно хорош.

??? На своём собственном ты будешь только дельту получать. Это как раз в первую очередь нужно тем, кто на тонких каналах, типа жопореза.

В смысле, мне не хотелось бы доверять пароль от своего аккаунта кому-то кроме тех, у кого он и так есть по техническим причинам.

>у кого он и так есть по техническим причинам.
у них есть только хэш, а пароля-то как раз и нету

оверхед где-то 3-4

нарисуй мне соап гдеб для передачи 1000 айдишников был оверхед 4, а не 10

> Но ему придется доверить свой логин и пароль от Лора.

кому ему? SOAP-клиенту? браузеру же ты этот пароль доверяешь. а клиент ровно так же и работать будет.

>нарисуй мне соап гдеб для передачи 1000 айдишников был оверхед 4, а не 10

<id>10228298</id> <id>10282992</id>

и так далее. на 1000 ID заглолвком можно пренебречь

Функций уже пять. И присоединяюсь - зачем это делать на SOAP? Хотя если заюзать cxf, будет и soap, и rest.

> Функций уже пять. И присоединяюсь - зачем это делать на SOAP? Хотя если заюзать cxf, будет и soap, и rest.

SOAP - как пример RPC. можно выбрать что-то другое (главное чтобы не было завязано на строго один язык программирования)

> кому ему?
jabber-транспорту, если он находится не на моем и не на макскомовом сервере.

А кто тебе его предложил?

>> кому ему?

jabber-транспорту, если он находится не на моем и не на макскомовом сервере.

а почему бы ему не находиться на ТВОЕМ сервере?

[10002,100292] - короче, и проще разбирать. SOAP слил.

> [10002,100292] - короче, и проще разбирать. SOAP слил.

Если есть какой-то RPC который так отвечает то я всегда за. SOAP - просто готовое решение. а это ты что предлагаешь?

json же, читуябельнее, присать въеб клиент для него — милое дело (в JavaScript разбирать его не надо), на остальных языках он парсится быстрее xml

> json же, читуябельнее, присать въеб клиент для него — милое дело (в JavaScript разбирать его не надо), на остальных языках он парсится быстрее xml

Читуябельнее, но JSON это всего навсего формат представления данных, а не RPC. фишка SOAP или XMLRPC (или аналогичного решения), что мы фактически вызываем функции на стороне сервера. и получаем их возвращаемые значения.

И кто мешает для того же самого пользоваться REST, гоняя туда-сюда json или простые параметры?

> Читуябельнее, но JSON это всего навсего формат представления данных, а

не RPC. фишка SOAP или XMLRPC (или аналогичного решения), что мы

фактически вызываем функции на стороне сервера. и получаем их

возвращаемые значения.

И нафига оно надо? Оно действительно что-то упрощает, или все же просто
добавляет бессмысленный слой абстракции?

>> не RPC. фишка SOAP или XMLRPC (или аналогичного решения), что мы

фактически вызываем функции на стороне сервера. и получаем их
возвращаемые значения.

И нафига оно надо? Оно действительно что-то упрощает, или все же просто
добавляет бессмысленный слой абстракции?

это удобнее разработчикам:

- если надо добавить новую функцию - не нужно думать о ее интерфейсе и транспорте

- проще написать тесты

> И кто мешает для того же самого пользоваться REST, гоняя туда-сюда json или простые параметры?

мы говорим о разных уровнях абстракции. да можно конечно вместо TCP-приложения писать IP-приложение. но только это будет на порядок сложнее (особенно в контексте имеющегося библиотечного инструментария) если тебе нужно непрерывное соединение с гарантией доставки :)

Уровень абстракции ровно один. Это все варианты RPC over HTTP, единственно, что в случае REST запросы получают дополнительную семантику. SOAP, однако, помимо оверхеда на трафик дает еще замечательный оверхед - маршалинг/анмаршалинг отнюдь не бесплатен.

> Уровень абстракции ровно один. Это все варианты RPC over HTTP, единственно, что в случае REST запросы получают дополнительную семантику. SOAP, однако, помимо оверхеда на трафик дает еще замечательный оверхед - маршалинг/анмаршалинг отнюдь не бесплатен.

маршалинг и анмаршалинг есть всегда. и отнюдь не бесплатен.

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

аналогия с TCP vs IP прямая

Со стороны сервера разницы никакой, только нагрузка меньше. Как я говорил, есть cxf. Он дает возможность писать и REST и SOAP бакэнды сопоставимой сложности с прозрачным маршалингом/анмаршалингом. Что касается клиентов - по-моему, уже для всего есть библиотеки для работы с json.

> Со стороны сервера разницы никакой, только нагрузка меньше. Как я говорил, есть cxf. Он дает возможность писать и REST и SOAP бакэнды сопоставимой сложности с прозрачным маршалингом/анмаршалингом. Что касается клиентов - по-моему, уже для всего есть библиотеки для работы с json.

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

1. запросить айдишники сообщений треда

2. запросить сообщение по айдишнику (возможно даже если весь тред)

3. запросить статистику по треду (чтобы знать есть ли новые сообщения)

4. запостить сообщение

пофик какой вариант, SOAP/REST/или какой другой. главное чтобы это

а. не зависело от форматирования собственно форума

b. просто реализовывалось.

пердешь и провокация, полноценный RPC на JSON я наваял за день

> пердешь и провокация, полноценный RPC на JSON я наваял за день

ну наваяй для лора описанные функции:

1. по ID треда - выдать ID всех его сообщений

2. по ID сообщения выдать его

3. по ID группы и номеру страницы выдать ID тредов с количеством сообщений в них (или с датой добавления последнего сообщения в нем)

4. принять у пользователя ID сообщения, ID треда, сабжект и сообщение и запостить в тред (если ID сообщения ненулевой - значит письмо-ответ, если нулевой - новый тред)

раз для тебя так это просто

Не будет xml, тем более xml-rpc. уже в 2003 просили maxcom-а сделать xhtml+css. Но рекламу же надо как-то показывать

чувачог, иди кури что такое rpc, и кури отличия rpc, от реализации морды к лору с использованием этого самого rpc. А может ты не прикидываешься таким глюпым?

> Не будет xml, тем более xml-rpc. уже в 2003 просили maxcom-а сделать xhtml+css. Но рекламу же надо как-то показывать

XHTML это совсем другое. для xhtml надо переделывать имеющийся движок. для rpc надо просто добавить пяток функций (файл этак в килобайт размером) еслиб не на яве а на перле я б сам написал, но тут движ на яве - :(

> чувачог, иди кури что такое rpc, и кури отличия rpc, от реализации морды к лору с использованием этого самого rpc. А может ты не прикидываешься таким глюпым?

никто не собирается реализовывать морду к lor, работающую онлайн. а речь идет о читалках, работающих оффлайн.

уже имеется два гейта LOR в news и в maillist, есть гейт LOR в читалку GUI (tkLor) и есть какой-то графопостроитель по тредам (это из того что я знаю).

так вот все это занимается парсингом вебстраничек: а потому требует _постоянного_ майнтенинга. был бы RPC чтобы запросить нужную информацию, то

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

- не требовали бы переписывания при изменениях в интерфейсе

- было бы просто написать всякие гейты к irc/jabber, которые тут многие просят

реализовывть морду с использованием RPC никто не просит. мы сами реализуем. мы просим дать нам этот RPC :)

> есть гейт LOR в читалку GUI (tkLor)

ЕМНИП, tkLor HTML парсит, не?

>> есть гейт LOR в читалку GUI (tkLor)

ЕМНИП, tkLor HTML парсит, не?

Блин, так я о том и говорю! Все внешние тулзы это делают. Потому и сабж! чтобы можно было их писать не делая парсинг HTML: HTML периодически меняется. там кнопочку прикрутят, сям текстик поправят. а RPC в этом плане меняться то незачем.

Меня ввело в заблуждение слово «гейт» =)
По-моему, no-dashi писал XML-интерфейс к ЛОРу да так и бросил, возникли там какие-то трудности

> Меня ввело в заблуждение слово «гейт» =)

ну да, гейт: по крону просматриваются треды которые изменились, по новой парсятся и новые сообщения записываются в базу. так работает и ньюс гейт и mail гейт. tkLor, подозреваю, работает примерно так же, только не по крону а по кнопкам

По-моему, no-dashi писал XML-интерфейс к ЛОРу да так и бросил, возникли там какие-то трудности

насколько я помню там речь шла строго о именно новой _веб_ морде. а я веду речь о сервисных функциях.

вот к примеру: мы на работе разрабатывали некую CRM которая учитывала все бизнеспроцессы в нашей фирме. разрабатывали несколько лет, примерно 10 человек. в итоге имеем огромный интерфейс (по сути внутренний вебсайт). если кто-то скажет «а давайте его на XML переделаем» так я его первый в очереди душить буду. а вот SOAP-интерфейс, который практически _весь_ функционал CRM может использовать был приделан примерно за два дня (для партнеров понадобился доступ, ну и поставили такую задачу)

это я о том что реализация RPC к уже имеющейся инфраструктуре обычно дело несложное

Сделать все можно. Вопрос в том, как maxcom на это посмотрит.

> Сделать все можно. Вопрос в том, как maxcom на это посмотрит.

ну вот ждемс что он скажет

реализовывть морду с использованием RPC никто не просит. мы сами реализуем. мы просим дать нам этот RPC :)

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

>> реализовывть морду с использованием RPC никто не просит. мы сами реализуем. мы просим дать нам этот RPC :)

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

я тебе в третий объясняю, эти прослойки УЖЕ написаны. (через одну из них я и пишу вот это сообщение: далее оно попадет на МТА, тот его скормит скрипту, тот запостит сюда, потом другой скрипт распознает что в этот тред добавлено новое сообщение, перепарсит его, найдет новые сообщения и вернет их на тот же MTA, который положит их в мой Maildir)

чтобы привести все эти прослойки к виду «не нужно периодически подпиливать парсер под новые изменения вебинтерфейса» и нужен rpc

я тебе в третий объясняю, эти прослойки УЖЕ написаны.

Клиника, чувак, это риальне клиника, тя не вылечить.

>> я тебе в третий объясняю, эти прослойки УЖЕ написаны.

Клиника, чувак, это риальне клиника, тя не вылечить.

шел бы ты отсюда

email -> LOR

> к LOR'у несколько человек приделывает разнообразные GUI. я вот немного поковырялся в сторону приделки гейта email -> LOR.

Зачем? Возьмите rss2email.

Что, рсс уже приходят о всех новых камментах?

Эмм, а зачем обо всех? Ну, можно, например, на трекер подписаться.

Смысл? Рсс и трекер ортогональны тому, о чём толкует ТС.