Mamut wrote:
>> > будет, во-первых, быстрее парсинга(ну или маппинга на объекты) >> > многословного ХМЛя. А во-вторых, вместо, скажем, гигабайта данных в день >> > удастся передать 700 мегабайтов в день на экономии только тэгов. Цифры >> > взяты с потолка, конечно, но можно и подсчитать: >> > Например, мы посылаем ИД клиента, тип уплаты, номер кредитки, >> > проверосный код, кол-во денег. > kan>Если 700 мегабайтов, 1 платёж — 700 байтов (а это много даже для > максимально многословного xml), то это миллион > kan>платежей, даже по одному доллару — это миллион долларов в день. > Знаешь, те кто имеет такие деньги — может положить > kan>себе крутейшие сети и этот трафик будет пофиг. > Экономить всегда полезно.
Это называется преждевременной оптимизацией.
> Это кстати, косвенное отражение общей тенденции сегодняшних дней — > "пофиг, что много, мы его задавим объемами сетей/компов/памяти". > Экономить разучились совсем.
Это дорого.
> Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю > Пошлите START > Пошлите информацию > Пошлите END
Не знаю, вот лог миранды:
Не знаю что всё это означает, честно говоря.
>> > Гипотетический код платежной системы: >> > >> > > payment::clientid=2ni3poicy5b8924v;ptype=VISA;ccno=1234567890123456;vcode=12345;amount=23.5;; >> > >> > >> > Максимально упрощенный ХМЛ: >> > >> > <payment clientid="2ni3poicy5b8924v" ptype="VISA" > ccno="1234567890123456" vcode="12345" amount="23.5" /> >> > У нас добавляется по 2 символа на значение, что при больших объемах >> > влетает в копеечку > kan>Экономия на спичках, назвается. > > Спички-спичками, но когда таких спичек много... > >> > Ну и, во-вторых, парсер ХМЛ уже сложнее. Ненамного, а оно нам нужно? > kan>Да, но его не надо писать, кто его пишет — сам себе злобный буратино. > > Как это не надо писать? Даже если его и написали, то это написал кто-то, > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда > не побьет по простоте вот это:
> // псевдо код
> MessageArray = split(message, "::");
> KeyValueArray = split(MessageArray(1), ";");
> for(...)
> {
> KeyValuePair = split(KeyValueArray[i], '=');
> }
>
> // где split может быть невероятно шустрым
А вот тоже самое, но для xml в случае DOM:
payment = message.getRootElement()
Вот дальше самое интересное, что ты не дописал, допиши если всё ещё считаешь, что будет просто.
function makePayment(clientId, amount, cardNo);
function checkCard(cardType, cardNo, cardVCode);
....
if(checkCard(payment.getAttribute("ptype"), payment.getAttribute("ccno"), payment.getAttribute("vcode"))
{
makePayment(payment.getAttribute("cientid"), payment.getAttribute("amount"), payment.getAttribute("ccno"))
}
А если заюзать какой-нибудь xml-object mapping, то будет вообще красота.
В случае SAX (скажем, что одним потоком можно обработать сколь угодно много запросов, которые не влезут в память) будет
чуть посложнее, конечно, но в случае поточной обработки твой подход будет гораздо сложнее.
> В то время, как для ХМЛ придется писать callback функции для SAX, долго > разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же > собственный велосипед будет приспособлен именно для наших нужд и > оптимизирован по самое нехочу?
Ну-ну.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, eao197, Вы писали:
E>Глеб, извини, но ты мог бы уже так дословно к словам не цепляться.
Собственно, я и обратил внимание на то, что рассуждения идут о протоколах разных уровней.
E>Для ISO 8583, например, вот.
Это уже смешно: http://jpos.org/products
ISO/Bridge — ISO-8583 Made Easy
But if you are not a Java shop, or even if you are, but you just want to focus on your business logic without having to deal with low level ISO-8583 communications details, then ISO/Bridge is probably an alternative you ought to evaluate.
You can think of ISO/Bridge as a blackbox that sits between your application and the ISO-8583 host(s). It uses an extremely easy to implement XML-based protocol that simplify the burden of dealing with ISO-8583 messages, bitmaps, channels, packagers, headers, multiplexers and the like.
E>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.
Проблема в том, что стандартных решений очень мало. Пока нет единого, всеми выполняемого решения(неважно, основано оно на xml или нет) каждый делает так как ему хочется. Иногда неплохо получается, но иногда и фигня выходит. Кстати, я не знаток платежных систем, но вроде бы у нас стандартизовали клиент-банк на основе XML.
), то какой же получится > компилятор? > А как вот этот, по-вашему, можно сделать вменяемым?
<elseif/> не отражает структуру документа. Можно хотя бы как <xsl:choose> сделать.
Ну и разобраться почему в @cond надо ставить javascript... может можно обойти это дело, что нибудь готовое заюзать,
xpath какой-нибудь.
Только не надо меня убеждать что
if(someting)
{
}
чем-то лучше чем
<if test="something">
</if>
При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не
придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
>> Экономить всегда полезно. kan>Это называется преждевременной оптимизацией.
Ну, я думаю, товарищи в payment gateway'e уже непреждевременной занимаются
>> Это кстати, косвенное отражение общей тенденции сегодняшних дней — >> "пофиг, что много, мы его задавим объемами сетей/компов/памяти". >> Экономить разучились совсем. kan>Это дорого.
Это верно
>> Читаю наискосок описание. Гы. Как туториал по общению через сокеты читаю >> Пошлите START >> Пошлите информацию >> Пошлите END kan>Не знаю, вот лог миранды: kan>
[skip] >> Как это не надо писать? Даже если его и написали, то это написал кто-то, >> доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда >> не побьет по простоте вот это:
kan>
>> // псевдо код
>> MessageArray = split(message, "::");
>> KeyValueArray = split(MessageArray(1), ";");
>> for(...)
>> {
>> KeyValuePair = split(KeyValueArray[i], '=');
>> }
>>
>> // где split может быть невероятно шустрым
kan>
kan>А вот тоже самое, но для xml в случае DOM:
kan>
kan>payment = message.getRootElement()
kan>
kan>Вот дальше самое интересное, что ты не дописал, допиши если всё ещё считаешь, что будет просто. kan>
kan>А если заюзать какой-нибудь xml-object mapping, то будет вообще красота.
У нас так же возможны ситуации, когда создание лишних объектов в памяти дорого.
kan>В случае SAX (скажем, что одним потоком можно обработать сколь угодно много запросов, которые не влезут в память) будет kan>чуть посложнее, конечно, но в случае поточной обработки твой подход будет гораздо сложнее.
Тут надо смотреть на реальных примерах, но кто ж их даст?
>> В то время, как для ХМЛ придется писать callback функции для SAX, долго >> разбирать структуру для DOM и т.п. Зачем? Если в нашем случае наш же >> собственный велосипед будет приспособлен именно для наших нужд и >> оптимизирован по самое нехочу? kan>Ну-ну.
M>> Экономить всегда полезно. GZ>Вообще-то нормальные девелоперы, для того чтобы уменьшить трафик включают gzip, который собственно именно для этого и предназначен. А через LZW алгоритмы, xml скукоживается на порядки.
Здравствуйте, GlebZ, Вы писали:
E>>Для ISO 8583, например, вот. GZ>Это уже смешно: GZ>http://jpos.org/products GZ>
GZ>ISO/Bridge — ISO-8583 Made Easy
GZ>But if you are not a Java shop, or even if you are, but you just want to focus on your business logic without having to deal with low level ISO-8583 communications details, then ISO/Bridge is probably an alternative you ought to evaluate.
GZ>You can think of ISO/Bridge as a blackbox that sits between your application and the ISO-8583 host(s). It uses an extremely easy to implement XML-based protocol that simplify the burden of dealing with ISO-8583 messages, bitmaps, channels, packagers, headers, multiplexers and the like.
Вообще-то говоря, вполне разумное решение. Получается возможность реализовывать клиентов на любом языке. Хоть на C#, хоть на Ruby, хоть на Perl. Вся работа с двоичными данными сосредоточена в java-вском коде.
Еще один пример: протоколы работы с MMS-ками реализованы на основе SOAP-а. Что позволяет реализовывать MMS-сервисы на чем хочешь -- хоть на C++, хоть на Java, хоть на Tcl. Хотя казалось бы, там overhead значительный должен выходить, ведь бинарные данные (картинки, звук) передаются в base64. И ничего, все замечаетльно пашет.
Это как раз примеры того, как XML используется по теме.
E>>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.
GZ>Проблема в том, что стандартных решений очень мало. Пока нет единого, всеми выполняемого решения(неважно, основано оно на xml или нет) каждый делает так как ему хочется. Иногда неплохо получается, но иногда и фигня выходит. Кстати, я не знаток платежных систем, но вроде бы у нас стандартизовали клиент-банк на основе XML.
Так вот и я про то, что в данном случае речь идет о какой-то нестандартной платежной системе. В которой разработчики могут творить, что хотят. Но, опять же, не зная подробностей, не хочется утвержать, что они напрасно от XML отказались. Может они платежи с каких-нибудь аппаратов делают, встроенные системы разрабатывают, где ресурсы не позвляют XML парсинг делать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, kan, Вы писали:
kan>Только не надо меня убеждать что kan>
kan>if(someting)
kan>{
kan>}
kan>
kan>чем-то лучше чем kan>
kan><if test="something">
kan></if>
kan>
kan>При использовании любого вменяемого xml-редактора — разницы никакой (теги сами закрываются, так что </if> писать не kan>придётся, обязательные аттрибуты сами печатаются, так что "test=" тоже набирать не придётся).
А какая альтернатива в XML будет, например, у:
if something && ( something_else || ( first && second && third ) )
...bla-bla-bla...
elsif another || yet_another || or_yet_another
...bla-bla-bla...
else
...trundec...
end
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
GZ>>Сложности возникают только когда начинают делать свои велосипеды из-за нереальной мысли что будет лучше. Как нибудь попробуй прочитать спецификацию XML(даже без остальных технологий). Он только кажется простым. И там учтено много подводных камней.
E>Здесь я с тобой согласен. Но меня вообще интересует, чтоже это за платежная система, которая вместо стандартных (хоть и сложных, и дорогих) решений позволяет использовать собственные key=value.
Нашел-таки Зрительная память — это вещь Ввел в гугле Payment Gateway и начал искать сайт, вид которого я отдаленно помнил
The Standard Transaction Submission API defines the information that can be submitted to the gateway for real-time transaction processing. The API consists of a set of fields that are required for each transaction, and a set of fields that are optional. Under the API, the gateway accepts a NAME/ VALUE pair. The NAME is the field name and indicates to the gateway what information is being submitted. VALUE contains the content of the field.
Дальше идут таблицы с необходимыми названиями полей.
И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
>> > Как это не надо писать? Даже если его и написали, то это написал кто-то, >> > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда >> > не побьет по простоте вот это:
Побило как ребёнка.
> У нас так же возможны ситуации, когда создание лишних объектов в памяти > дорого.
Ну не создавай. Кто ж заставляет?
> kan>В случае SAX (скажем, что одним потоком можно обработать сколь > угодно много запросов, которые не влезут в память) будет > kan>чуть посложнее, конечно, но в случае поточной обработки твой подход > будет гораздо сложнее. > Тут надо смотреть на реальных примерах, но кто ж их даст?
Ты хотя бы прикинь код на твоих любимых split-ах, который будет парсить поток строк <payment/>, что ты приводил, и,
скажем, вызывать checkCard/makePayment и записывать в выходной поток результат вроде
<result clientid="2ni3poicy5b8924v"/>
<result clientid="vqxernty853ty32q" error="1244">Мятые купюры не принимаем</result>
и сравни это с банальным SAX-фильтром.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
eao197 wrote:
> А какая альтернатива в XML будет, например, у: > > if something && ( something_else || ( first && second && third ) ) > ...bla-bla-bla... > elsif another || yet_another || or_yet_another > ...bla-bla-bla... > else > ...trundec... > end
Если что-то типа подхода xslt (для условий используется xpath):
<choose>
<when test="something and (something_else or (first and second and third))">
...bla-bla-bla...
</when>
<when test="another or yet_another or or_yet_another">
...bla-bla-bla...
</when>
<otherwise>
...trundec...
</otherwise>
</choose>
Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в
html/svg javascript тоже активно юзается, никто не жалуется.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mamut, Вы писали:
M>И я на самом деле вас ... кхм ... напарил Там инициируется POST запрос к серверу по HTTPS, в котором передаются пары Name/Value. То есть, Authorize.net получает уже готовый разбор значений на халяву.
* November 1996 — Authorize.Net is founded in Provo, UT.
* March 1997 — Authorize.Net launches the eCheck.Net service.
* September 1997 — Authorize.Net partners with its first reseller, U.S. Merchant Systems, initiating its world class reseller channel.
* December 1998 — Authorize.Net surpasses 10,000 active merchants.
основные проектные решения они принимали, когда XML еще не был в таком фаворе, как сейчас.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
>>> > Как это не надо писать? Даже если его и написали, то это написал кто-то, >>> > доверия к кому может и не быть. И _в любом_ случае работа с ХМЛ никогда >>> > не побьет по простоте вот это: kan>Побило как ребёнка.
Только при условии создания DOM-объекта
>> У нас так же возможны ситуации, когда создание лишних объектов в памяти >> дорого. kan>Ну не создавай. Кто ж заставляет?
Тогда не получится легкости типа payment = message.getRootElement()
>> kan>В случае SAX (скажем, что одним потоком можно обработать сколь >> угодно много запросов, которые не влезут в память) будет >> kan>чуть посложнее, конечно, но в случае поточной обработки твой подход >> будет гораздо сложнее. >> Тут надо смотреть на реальных примерах, но кто ж их даст? kan>Ты хотя бы прикинь код на твоих любимых split-ах, который будет парсить поток строк <payment/>, что ты приводил, и, kan>скажем, вызывать checkCard/makePayment и записывать в выходной поток результат вроде kan>
kan><result clientid="2ni3poicy5b8924v"/>
kan><result clientid="vqxernty853ty32q" error="1244">Мятые купюры не принимаем</result>
kan>
kan>и сравни это с банальным SAX-фильтром.
Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа response::key=value;;
Правда, оказалось, что я все же был неправ и тот gateway работает по-другому
eao197 wrote:
> Судя по их истории <http://www.authorize.net/company/aboutus/>: > * November 1996 — Authorize.Net is founded in Provo, UT. > * March 1997 — Authorize.Net launches the eCheck.Net service. > * September 1997 — Authorize.Net partners with its first reseller, U.S. > Merchant Systems, initiating its world class reseller channel. > * December 1998 — Authorize.Net surpasses 10,000 active merchants. > основные проектные решения они принимали, когда XML еще не был в таком > фаворе, как сейчас.
Не то что фаворе, а его вообще не было! Первая релизная версия <br />
спецификации от 1998-года, когда Authorize.Net уже развернулись на всю катушку.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kan, Вы писали:
kan>Если что-то типа подхода xslt (для условий используется xpath): kan>
kan><choose>
kan> <when test="something and (something_else or (first and second and third))">
kan> ...bla-bla-bla...
kan> </when>
kan> <when test="another or yet_another or or_yet_another">
kan> ...bla-bla-bla...
kan> </when>
kan> <otherwise>
kan> ...trundec...
kan> </otherwise>
kan></choose>
kan>
kan>Хотя в условиях и javascript можно использовать. Испольозование xml не запрещает использовать другие языки. Вон, в kan>html/svg javascript тоже активно юзается, никто не жалуется.
А теперь представь, что у тебя 200-ти строк такого кода, в которых ты ищещь баг. Распечатываешь, чтобы прошерстить исходники в спокойной обстановке с карандашом в руках. Тебе будет удобно среди <тегов> суть выискивать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, ZevS, Вы писали:
TBG>>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
ZS>Пожалуйста: ZS>
ZS>Регулярный простой синтаксис.
Особенно для тети Тани. Несомненно. ZS>Возможность просматривать данные в любом виде
Теперь следует объяснить пользователю его эту возможность и он возрадуется. Быть может. ZS>Легкость контроля валидности
Ты, как пользователь HTML, часто его на валидность проверяешь? ZS>Относительная легкость интеграции и, возможно, перехода на новую версию продукта
Мне, как пользователю это совершенно фиолетово. ZS>Относительная легкость создания своих средств автоматизации и их простота
Опять же, предыдующий пункт. ZS>Относительная легкость анализа
Для дотошного пользователя, может быть. ZS>
ZS>Можно продолжить.
Не сомневаюсь. Минусы мы опустим. Опять же зависит все от того, кто твой пользователь и что он будет делать. Думаю, при описании шаблона отчета в xml не каждый из пользователей решится это сделать сам. Потому что:
Ну не хочется ему что-то изучать, если только сильно не придется, а если и придется, то лучше придумать какой-нибудь отмаз. Опять же, от ситуации зависит;
Все же ХыМыЛ не даст сделать все легко и удобно и придется что-то писать, но зачем? Лучше сказать, что язык описания непригоден и обосновать это;
Да и вообще, на то он и пользователь конечный, чтобы не знать что такое XML.
Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE.
Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит.
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, ZevS, Вы писали:
TBG>>>Хотелось бы послушать про преимущества ХыМыЛа для конечного пользователя продукта.
ZS>>Пожалуйста: ZS>>
ZS>>Регулярный простой синтаксис. TBG>Особенно для тети Тани. Несомненно. ZS>>Возможность просматривать данные в любом виде TBG>Теперь следует объяснить пользователю его эту возможность и он возрадуется. Быть может. ZS>>Легкость контроля валидности TBG>Ты, как пользователь HTML, часто его на валидность проверяешь? ZS>>Относительная легкость интеграции и, возможно, перехода на новую версию продукта TBG>Мне, как пользователю это совершенно фиолетово. ZS>>Относительная легкость создания своих средств автоматизации и их простота TBG>Опять же, предыдующий пункт. ZS>>Относительная легкость анализа TBG>Для дотошного пользователя, может быть. ZS>>
Извините, но это демагогия.
TBG>Даже конфигурационный файл оказывается проще что-то в стиле KEY=VALUE. TBG>Я не за языки вместо ХМЛ — они тоже проблему не решат. Я за то, чтобы конечный пользователь владел все же мышой или чем-нибудь там и особо не напрягался, так как не любит.
Правда? А если конфигурация — это не пара значений, а сложная иерархическая структура?
Mamut wrote:
> kan>Побило как ребёнка. > Только при условии создания DOM-объекта
Ну да, что-то я не подумал, ведь MessageArray, KeyValueArray — в паралльельной вселенной создаются и места не занимают.
>> > У нас так же возможны ситуации, когда создание лишних объектов в памяти >> > дорого. > kan>Ну не создавай. Кто ж заставляет? > Тогда не получится легкости типа payment = message.getRootElement()
Используй SAX.
> kan>и сравни это с банальным SAX-фильтром. > Ну, возвращать-то он тоже будет пары key-value, то есть что-то типа > response::key=value;;
Пусть так. Легче не станет.
> Правда, оказалось, что я все же был неправ и тот gateway работает > по-другому <http://rsdn.ru/Forum/Message.aspx?mid=2137550&only=1>
Здравствуйте, Cyberax, Вы писали:
>> Вот теперь следующая идея ждет своего воплощения: встраивать >> Ruby-интерпритатор прямо в приложение, чтобы DSL им парсился и >> информация из DSL непосредственно в приложение поступала. C>А зачем?
Ну у меня в коде используется следующий подход: есть набор классов, объекты которых хранят конфигурационную информацию. Именно эти объекты используются в программе.
Есть так же процедуры, которые занимаются парсингом конфигурационных файлов и созданием вышеуказанных объектов. Как правило эти процедуры используют какую-либо библиотеку классов (для XML или моего формата). В случае использования моего формата, получается еще параллельная система классов-парсеров (в случае XML вместо них набор процедур, обрабатывающих DOM).
К этому еще добавляется набор Ruby-скриптов, которые из компактного DSL-я генерят пространные конфигурационные файлы.
Идея состоит в том, чтобы процедуры парсинга конфигов использовали сразу Ruby интерпритатор. А реализация DSL на Ruby могла формировать мои конфигурационные объекты в программе напрямую. Т.е., убрать промежуточные слои.
Но все это хорошо для случаев, когда приложение не должно сохранять конфигурацию обратно. Хотя, сейчас развитие проекта ParseTree обещает сделать возможным восстановление Ruby-кода.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
eao197 wrote:
> А теперь представь, что у тебя 200-ти строк такого кода, в которых ты > ищещь баг. Распечатываешь, чтобы прошерстить исходники в спокойной > обстановке с карандашом в руках. Тебе будет удобно среди <тегов> суть > выискивать?
Дело привычки и ничего более.
Я не помню, чтобы я когда либо код печатал и с карандашом над ним сидел, мне неудобно бумагу юзать.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Ввел в гугле Payment Gateway и начал искать сайт, вид которого я отдаленно помнил 
