Здравствуйте, AndrewVK, Вы писали:
GZ>> Вопрос по тому, а как же строку накормить датой — пожалуй один из наиболее частых. AVK>То есть лично ты дату отдаешь строкой, как это делаешь в случае URL?
Ессно — нет. Есть стандартный способ передачи параметров через DbParameters или аналогичные структуры в любом интерфейсе работы с БД. Не использовать его по назначению могут только новички.
GZ>>Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры. AVK>Есть. Тот же TOP/LIMIT/FIRST в большинстве серверов. Или ORDER BY.
Второе — зависит от используемой базы. Первое, так как целочисленное значение, легко делается и так.
AVK>Только это не означает, что там, где таки можно параметрами, стоит руками собирать строку. Точно так же и с URL. В твоем примере вполне можно использовать какой нибудь LinkLabel и не заниматься ручным перекодированием.
При чем тут LinkLabel? LinkLabel — winform'овская штукенция предназначенная для использования WinForms. Пример был описан от ASP.NET. А трабла тут следующая. Строка запроса должна быть переведена в стандарт Html а затем в стандарт Url. При этом, Html стандарт держит различные кодировки, но для Url — кодировка одна. Все что больше 7 бит, пробелы и служ. символы должно переводится в процентики с кодами. Амперсенд — служебный в обоих случаях.
Стандартные способы на генерации get запроса(из того что выпущено на данный момент):
1. Uri, UriBuilder — подходит для WebRequest но не для ASP.NET. В Html формат — не перекодирует.
2. HyperLink — перекодирует в формат Html. Но он перекодирует строку. В нем нет разделения на параметры, таким образом, амперсенд всегда является разделителем параметров. То есть требуется дополнительное перекодирование по url формату.
3. HttpUtility, HttpServerUtility — практически то что нужно, но море ручного труда по той же сборки в строку запроса GET.
А нормальных, не ручных, средств сборки get запросов — нету. В отличие от той же базы данных.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
...The AMQP model was conceived with the following goals:
1. To support the semantics required by the financial services industry.
2. To provide the levels of performance required by the financial services industry.
3. To be easily extended for new kinds of message routing and queuing.
4. To permit the server's specific semantics to be programmed by the application, via the protocol.
5. To be flexible yet simple.
...The design of the AMQP Model was driven by these requirements:
1. To guarantee interoperability between conforming implementations.
2. To provide explicit control over the quality of service.
3. To support any middleware domain: messaging, file transfer, streaming, RPC, etc.
4. To accommodate existing open messaging API standards (for example, Sun's JMS).
5. To be consistent and explicit in naming.
6. To allow complete configuration of server wiring via the protocol.
7. To use a command notation that maps easily into application-level API's.
8. To be clear, so each operation does exactly one thing.
The design of the AMQP transport layer was driven by these main requirements, in no particular order:
1. To be compact, using a binary encoding that packs and unpacks rapidly.
2. To handle messages of any size without significant limit.
3. To permit zero-copy data transfer (e.g. remote DMA).
4. To carry multiple sessions across a single connection.
5. To allow sessions to survive network failure, server failover, and application recovery.
6. To be long-lived, with no significant in-built limitations.
7. To be asynchronous.
8. To be easily extended to handle new and changed needs.
9. To be forward compatible with future versions.
10. To be repairable, using a strong assertion model.
11. To be neutral with respect to programming languages.
12. To fit a code generation process.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, GlebZ, Вы писали:
GZ>>>Но с SQL ситуация все таки значительно легче. Там нет способа кроме передачи через параметры. AVK>>Есть. Тот же TOP/LIMIT/FIRST в большинстве серверов. Или ORDER BY. GZ>Второе — зависит от используемой базы.
Ты думаешь я об этом не знал?
AVK>>Только это не означает, что там, где таки можно параметрами, стоит руками собирать строку. Точно так же и с URL. В твоем примере вполне можно использовать какой нибудь LinkLabel и не заниматься ручным перекодированием. GZ>При чем тут LinkLabel? LinkLabel — winform'овская штукенция предназначенная для использования WinForms.
Я про WebForms, не помню как там аналогичный контрол называлсч. Главное, у него есть свойство Uri, которое при генерации HTML закодируется как оно надо. Полный аналог параметров SQL запроса.
GZ>Строка запроса должна быть переведена в стандарт Html а затем в стандарт Url. При этом, Html стандарт держит различные кодировки, но для Url — кодировка одна. Все что больше 7 бит, пробелы и служ. символы должно переводится в процентики с кодами. Амперсенд — служебный в обоих случаях.
Ты думаешь я об этом не знал?
GZ>2. HyperLink — перекодирует в формат Html. Но он перекодирует строку. В нем нет разделения на параметры, таким образом, амперсенд всегда является разделителем параметров. То есть требуется дополнительное перекодирование по url формату.
Напиши своего наследника, делов то.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP :). Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP. C>[стошнило] C>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет.
Здравствуйте, netch80, Вы писали:
C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. N>А что для этого нужно? Давай RFC draft нарисуем
Для чего нужны load ballancing и failover?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Я про WebForms, не помню как там аналогичный контрол называлсч. Главное, у него есть свойство Uri, которое при генерации HTML закодируется как оно надо. Полный аналог параметров SQL запроса.
Нету. Было-бы, я бы так не возмущалси, не плакалси горючими слезами.
GZ>>2. HyperLink — перекодирует в формат Html. Но он перекодирует строку. В нем нет разделения на параметры, таким образом, амперсенд всегда является разделителем параметров. То есть требуется дополнительное перекодирование по url формату. AVK>Напиши своего наследника, делов то.
Наследников нужно будет чуть ли не на 50 процентов контролов делать . Get — запросы это не только в HyperLink. А исчо есть клиентские контролы. Они ваще не перекодируют в html, а требуют чтобы в них так и писали. То есть:
<a href="MyPage.html?name=n1&name" />
и
<asp:Hyperlink runat="server" NavigateUrl="MyPage.html?name=n1&name"/>
сгенерят разный код. Первый сгенерит амперсанды один в один. Второй заменит & на &. А еще иногда нужно всю эту шарагу на уровне JavaScript собирать. Там тоже те же тараканы, весом поменьше.
Вобщем, сборка строки в SQL и URL — разные по сложности вещи.
Здравствуйте, GlebZ, Вы писали:
GZ>Наследников нужно будет чуть ли не на 50 процентов контролов делать
Только это не проблема HTTP, а проблема ASP.NET.
GZ>Вобщем, сборка строки в SQL и URL — разные по сложности вещи.
Они разные по сложности, потому что в одном случае есть готовая реализация, а в другом нету. Инкапсулировать все эти СТРАШНЫЕ УЖАСЫ в простенькое API — задачка для студента 3 курса.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, GlebZ, Вы писали:
GZ>Наследников нужно будет чуть ли не на 50 процентов контролов делать . Get — запросы это не только в HyperLink. А исчо есть клиентские контролы. Они ваще не перекодируют в html, а требуют чтобы в них так и писали. То есть: GZ><a href="MyPage.html?name=n1&name" />
Так писать неправильно. Символ '&', являющийся частью URI, при использовании в HTML должен кодироваться в &.
И>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний.
....попробуй объяснить загадку природы TCP/IP. как бы бинарный и о таких проблеммах не слышал
И>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук.
когда ты последний раз отлаживал TCP/IP?
И>А если еще уволишься, и новому человеку придется разбираться со всей этой байдой, ууу.... Админам может быть удобно. Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола).
да ты крут....визуально английскую и русскую А Е и О отличаешь...
И>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто на ура, а можно и автогенераторами воспользоваться.
очень удобно пользоваться специализированными инструментами. например IDE для программинга, где в основе банальные текстовые файлы. или ноутпэд наш выбор? ....дикари!
И>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
Здравствуйте, Shabi, Вы писали:
И>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. S>....попробуй объяснить загадку природы TCP/IP. как бы бинарный и о таких проблеммах не слышал
А функции типа htons/htonl видел?l
И>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. S>когда ты последний раз отлаживал TCP/IP?
Протокол на основе HTTP в последний раз я, лично, отлаживал сегодня.
Здравствуйте, WolfHound, Вы писали:
C>>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. N>>А что для этого нужно? Давай RFC draft нарисуем WH>Для чего нужны load ballancing и failover?
Вот говоришь ты по телефону. А сервер вдруг сдох (выпал из сети, etc.). Хотелось бы, чтобы оно всё само переключило на резервный сервер, без обрыва соединения.
Здравствуйте, netch80, Вы писали:
C>>[стошнило] C>>SIP вообще не совместим с нормальным load ballancing'ом и failover'ом. Так что на титул "лучший протокол" он не тянет. N>А что для этого нужно? Давай RFC draft нарисуем
Ну "большой" телеком это вроде умеет, осталось только узнать как
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Shabi, Вы писали: S>>ага — пример заслал я на сервер запросы в последовательности q1, q2, q3...а на сервере оказываеца запрос S>>q1 выполняется долше всего... S>Открывай несколько параллельных коннектов. S>>...я ж говорю...HTTP ОТСТОЙ S>А какой протокол умеет автоматически переупорядочивать запросы?
Здравствуйте, Игoрь, Вы писали:
И>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один из них, реализовать оба ? И написать конвертор из одного в другой ? При отладке используем текстовый, в релизе — бинарный ?
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один из них, реализовать оба ?
Например, HTTP вполне себе поддерживает оба PD>И написать конвертор из одного в другой ? При отладке используем текстовый, в релизе — бинарный ?
Угу. И получить странности поведения в релизе, которые не воспроизводятся в дебаге? Отличная идея.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Игoрь, Вы писали:
И>>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
PD>А нельзя вместо "или" употребить "и" ? Вместо того , чтобы выбрать один из них, реализовать оба ? И написать конвертор из одного в другой ? При отладке используем текстовый, в релизе — бинарный ?
Два разных кода для дебага и релиза? Я надеюсь, среди нормальных людей нет таких, кто всерьёз (а не потрепаться) думает о таком;))
P.S. На самом деле, один частный случай подобного рода можно придумать. Но с границей не между отладочной и релизной версией, а скорее между режимами работы для каждой из них — если есть проверенная библиотека ASN.1 представлений, можно переключаться между BER (или вообще PER;)) для обычной работы и XER для случая, когда надо в чём-то разобраться. Но я думаю, что первый же глюк собственно библиотеки выбросит эту идею нафигъ и, возможно, с её автором.:)
Здравствуйте, Shabi, Вы писали:
И>>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний. S>....попробуй объяснить загадку природы TCP/IP. :xz: как бы бинарный и о таких проблеммах не слышал
Ты что курил? У него эти проблемы в полный рост — если не сделаешь ntohl при вытаскивании хоста из пакета, результат будет, мягко говоря, не тот, что ожидался. И странно бы, если где-то было бы хоть как-то иначе.
И>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. А с бинарным протоколом протрешь до дыр спецификацию, и без нее как без рук. S>когда ты последний раз отлаживал TCP/IP?
Я не думаю, что у кого-то тут есть собственная реализация TCP/IP, но я, например, смотрел tcpdump'ы и запускал tshark я не далее чем вчера. И таки да, видел бинарную часть и даже умудрялся в ней читать те поля, смещения которых знаю наизусть (а остальные пропускал, ибо лезть открывать /usr/include/netinet/in.h было облом). Ты вот навскидку сможешь прочитать список опций TCP и указать, где именно в пакете описано, например, scale размера окна? Только не подглядывать в доку.
И>>А если еще уволишься, и новому человеку придется разбираться со всей этой байдой, ууу.... Админам может быть удобно. Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола). S>да ты крут....визуально английскую и русскую А Е и О отличаешь... :wow:
Английская и русская буквы ни при чём. Это проблемы того уровня, который в таких протоколах крайне редко случается (и для них можно, например, шрифты iso-1 включить), может, один случай на десять тысяч, обычно реже, и необходимость копать в этом направлении видна сразу. Если ты вспоминаешь контекст баз данных — да, там такое бывает часто. Но не в служебных данных сетевого протокола.
И>>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто на ура, а можно и автогенераторами воспользоваться. S>очень удобно пользоваться специализированными инструментами. например IDE для программинга, где в основе банальные текстовые файлы. или ноутпэд наш выбор? ....дикари!
Дикарь тут именно ты. Потому что вместо использования передового опыта человечества (который сводится в данном случае к одной простой норме: "лучше делать удобнее для человека, чем для компьютера, если это не слишком дорого") — трясёшься над заветами отцов, которые их выработали находясь на крайнем севере где нечего есть кроме рыбы и ягеля, то есть прошу прощения — на компьютерах мощности в пару тысяч "слов" странной размерности, где не было нормального компилятора и приходилось дрожать над каждым битом.
И>>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный. S>странный опыт...
У тебя — да. Потому что ты до сих пор не освободился от опыта тех времён и мест, где надо было экономить каждый байт и где не было нормальных средств вообще ни для чего.
Там где текст был бы реально слишком дорог — например, уровни 1-4 традиционной народной OSI, или исполняемые файлы — его никто не втискивает. Там же, где его можно использовать — его используют.
Здравствуйте, netch80, Вы писали:
N>Я не думаю, что у кого-то тут есть собственная реализация TCP/IP, но я, например, смотрел tcpdump'ы и запускал tshark я не далее чем вчера.
Кстати, у меня есть, на базе cipsuite
Так как у меня требование, чтобы TCP-сессии выживали между перезагрузками устройства.
Здравствуйте, Gaperton, Вы писали:
G>Вообще то ты совсем прав. Самая страшная тайна состоит в том, что лучший на сегдня протокол вовсе не HTTP, а SIP . Для тех применений, для которых не оптимален HTTP (а их большинство) — оптимален SIP (Session Initiation Protocol), который также является стандартом IETF, и взял все лучшее от HTTP.
Полностью согласен! После довольно продолжительных ковыряний в данном протоколе о нем остались самые лучшие воспоминания
. Get — запросы это не только в HyperLink. А исчо есть клиентские контролы. Они ваще не перекодируют в html, а требуют чтобы в них так и писали. То есть:
как бы бинарный и о таких проблеммах не слышал
