Саn you hеаr mе - Ты можешь меня здесь?
Маniсurе - Деньги лечат
I hаvе bееn thеrе - У меня там фасоль
Gоd оnlу knоws - Единственный нос бога
Wе аrе thе сhаmрiоns - Мы шампиньоны
Dо yоu fееl аlright? - Ты справа всех знаешь?
Вуе bуе bаbу, bаbу gооd bуе - Купи, купи ребенка, ребенок - хорошая покупка
То bе оr nоt tо bе? - Пчеле или не пчеле?
I fеll in lоvе - Я свалился в любовь
Just in саsе - Только в портфеле
I will nеvеr givе uр - Меня никогда не тошнит
Оh dеаr! - Ах, олень!
I sаw mу hоnеу tоdау - Я пилю мой мёд сегодня
I'm gоing tо mаkе уоu minе - Я иду копать тебе шахту
Finnish реорlе - Конченые люди
Рhоnе sеllеr - Позвони продавцу
Gооd рrоduсts - Бог на стороне уток
Lеt's hаvе а раrtу - Давайте организуем партию
Wаtсh оut! - Посмотри снаружи!
I knоw his stоrу wеll - Я знаю его исторический колодец
Undressed custom model - Голая таможенная модель
May God be with you - Майская хорошая пчелка с тобой
Bad influence - Плохая простуда
Let's have a party - Давайте организуем партию
Press space bar to continue – Космический бар прессы продолжает…
I love you baby - Я люблю вас, бабы!
I'm just asking - Я всего лишь король жоп
Let it be – Давайте есть пчёл
Колхоз дело добровольное
Заранее извиняюсь. тема так сказать не в тему, в общем не знаю я куда это засунуть. А идея такая. Многим из присутствующих приходится лопатить разные мануалы на буржуйском. Причем не знаю кому как, но мне немножко обидно сознавать что это работа была выполнена кем-то и возможно не один раз. Поэтому я пришел к такой мысле- а чобы нам не взять и не начать дружно толпой переводить разные документы нужные.Тут вот разговор поднялся на тему форумов новых.Вношу свою лепту. Давайте откроем форум технического английского.Я к примеру не совсем дуб, но частенько и в словарик приходится заглядывать и на интуицию надеяться. А так можно было бы обратиться с вопросам по каким нибудь терминам непонятным.
Я понимаю что если сам, то глядишь и язык выучишь, но я бы предпочел его учить в процессе перевода тех документов, за которые еще никто не брался. Опять же намного легче вникать когда смотришь на перевод и оригинал, сопоставлять можно, ума набираться. А результаты работы форума в готовом виде выкладывать на сайте, я так думаю народ будет благодарен. Для начала предлагаю добить RFC2068_http_eng, он вроде как не до конца переведен. Схема работы такая.Берем предложение(1,2,10-сколько не лень)переводим, выкладываем в порядке предложение-перевод-следующее предложение. Желающий поучавствовать дает перевод последнего непереведенного куска и добавляет следующий и так до победного. Вот такая в общем мысль. Дабы не быть голословным-
13 Caching in HTTP
13 Кеширование в HTTP
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches.
HTTP обычно используется в распределенных информационных системах,где работа может быть улучшена путем кеширования ответов.
The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible.
Протокол HTTP/1.1 включает ряд элементов, предназначенных для улучшения, насколько это возможно, работы кеширования.
Because these elements are inextricable from other aspects of the protocol, and because they interact with each other,
it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.
Поскольку эти элементы неразрывно связаны с другими аспектами протокола и взаимосвязаны друг с другом, будет лучше описать базовую схему HTTP отдельно от детального описания методов, заголовков, кодов ответов.
Caching would be useless if it did not significantly improve performance.
Кеширование не используется, если оно улучшает качество работы незначительно.
The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases.
Целью кеширования в HTTP/1.1 является устранить потребность слать запросы в одних случаях и полные ответы в других.
The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism
for this purpose (see section 13.3).
В первом случае сокращается число запрос/ответов требуемых для многих операций, мы используем в этом случае "expiration" механизм(expiration-истечение срока)(см.главу13.2). Во втором случае сокращается требования к пропускной способности канала, мы используем в этом случае "validation" механизм(validation-подтверждение).(см.главу13.3)
Следующий не переведённый блок
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client.
Я понимаю что если сам, то глядишь и язык выучишь, но я бы предпочел его учить в процессе перевода тех документов, за которые еще никто не брался. Опять же намного легче вникать когда смотришь на перевод и оригинал, сопоставлять можно, ума набираться. А результаты работы форума в готовом виде выкладывать на сайте, я так думаю народ будет благодарен. Для начала предлагаю добить RFC2068_http_eng, он вроде как не до конца переведен. Схема работы такая.Берем предложение(1,2,10-сколько не лень)переводим, выкладываем в порядке предложение-перевод-следующее предложение. Желающий поучавствовать дает перевод последнего непереведенного куска и добавляет следующий и так до победного. Вот такая в общем мысль. Дабы не быть голословным-
13 Caching in HTTP
13 Кеширование в HTTP
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches.
HTTP обычно используется в распределенных информационных системах,где работа может быть улучшена путем кеширования ответов.
The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible.
Протокол HTTP/1.1 включает ряд элементов, предназначенных для улучшения, насколько это возможно, работы кеширования.
Because these elements are inextricable from other aspects of the protocol, and because they interact with each other,
it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.
Поскольку эти элементы неразрывно связаны с другими аспектами протокола и взаимосвязаны друг с другом, будет лучше описать базовую схему HTTP отдельно от детального описания методов, заголовков, кодов ответов.
Caching would be useless if it did not significantly improve performance.
Кеширование не используется, если оно улучшает качество работы незначительно.
The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases.
Целью кеширования в HTTP/1.1 является устранить потребность слать запросы в одних случаях и полные ответы в других.
The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism
for this purpose (see section 13.3).
В первом случае сокращается число запрос/ответов требуемых для многих операций, мы используем в этом случае "expiration" механизм(expiration-истечение срока)(см.главу13.2). Во втором случае сокращается требования к пропускной способности канала, мы используем в этом случае "validation" механизм(validation-подтверждение).(см.главу13.3)
Следующий не переведённый блок
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client.
Ага технический английский инженеров - бауманцев
Кто же таким переводом будет пользоваться?? Или я опять со своим пессимизмом ....
Код:
Кто же таким переводом будет пользоваться?? Или я опять со своим пессимизмом ....
Насчёт форума идея хорошая... кстати на lingvo.ru подобного форума нет? :???: А вот с переводом текста...мне кажется это почти не возможно...
Caching would be useless if it did not significantly improve performance.
Кеширование не используется, если оно улучшает качество работы незначительно.
-------------------------------------------------------
Я бы это перевёл так: "Кэширование было бы бесполезно, если бы оно значительно не увеличивало быстродействие"
А это
----------------------------------------------------------
The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases.
Целью кеширования в HTTP/1.1 является устранить потребность слать запросы в одних случаях и полные ответы в других.
---------------------------------------------------------
так:
Задача кэширования в HTTP/1.1 состоит в избежании необходимости слишком часто отсылать запросы и полные ответы .
...ну за последнее предложение не ручаюсь :angel: но мне кажется так гораздо понятнее... у кого варианты?
Кеширование не используется, если оно улучшает качество работы незначительно.
-------------------------------------------------------
Я бы это перевёл так: "Кэширование было бы бесполезно, если бы оно значительно не увеличивало быстродействие"
А это
----------------------------------------------------------
The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases.
Целью кеширования в HTTP/1.1 является устранить потребность слать запросы в одних случаях и полные ответы в других.
---------------------------------------------------------
так:
Задача кэширования в HTTP/1.1 состоит в избежании необходимости слишком часто отсылать запросы и полные ответы .
...ну за последнее предложение не ручаюсь :angel: но мне кажется так гораздо понятнее... у кого варианты?
Цитата:
Originally posted by ReDrum
Ага технический английский инженеров - бауманцев
...
Кто же таким переводом будет пользоваться?? Или я опять со своим пессимизмом ....
Ага технический английский инженеров - бауманцев
...
Кто же таким переводом будет пользоваться?? Или я опять со своим пессимизмом ....
Не, Редрум, здесь ты как никогда прав, и твой пессимизм как раз таки уместен. Но вся сила форума в том что никто мимо ошибки не пройдет. Я себе к примеру с трудом представляю тебя, прошедшего мимо моей ошибки. Если я не прав-поправь меня и я поправлюсь. Сам видишь-народ начинает втягиватся. А насчет невозможности ничего не скажу-слишком часто я это слово слышу. Чего бояться, кого стесняться?
На lingvo.ru мы потеряемся, там тематика английский язык, а нам нужна на английском документация.
Because these elements are inextricable from other aspects of the protocol, and because they interact with each other,
it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.
Поскольку эти элементы неразрывно связаны с другими аспектами протокола и взаимосвязаны друг с другом, будет лучше описать базовую схему HTTP отдельно от детального описания методов, заголовков, кодов ответов.
-----------------------------------
Поскольку эти элементы зависят от определённых аспектов протокола и взаимодействуют друг с другом, будет полезно описать основную схему кэширования HTTP отдельно от детального описания методов, заголовков, кодов ответов и т.д.
it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.
Поскольку эти элементы неразрывно связаны с другими аспектами протокола и взаимосвязаны друг с другом, будет лучше описать базовую схему HTTP отдельно от детального описания методов, заголовков, кодов ответов.
-----------------------------------
Поскольку эти элементы зависят от определённых аспектов протокола и взаимодействуют друг с другом, будет полезно описать основную схему кэширования HTTP отдельно от детального описания методов, заголовков, кодов ответов и т.д.
Итого имеем:
13 Кеширование в HTTP
HTTP обычно используется в распределенных информационных системах,где работа может быть улучшена путем кеширования ответов.
Протокол HTTP/1.1 включает ряд элементов, предназначенных для улучшения, насколько это возможно, работы кеширования.
Поскольку эти элементы зависят от определённых аспектов протокола и взаимодействуют друг с другом, будет полезно описать основную схему кэширования HTTP отдельно от детального описания методов, заголовков, кодов ответов и т.д.
Кэширование было бы бесполезно, если бы оно значительно не увеличивало быстродействие.
Задача кэширования в HTTP/1.1 состоит в избежании необходимости слишком часто отсылать запросы и полные ответы.
В первом случае сокращается число запрос/ответов требуемых для многих операций, мы используем в этом случае "expiration" механизм(expiration-истечение срока)(см.главу13.2). Во втором случае сокращается требования к пропускной способности канала, мы используем в этом случае "validation" механизм(validation-подтверждение).(см.главу13.3)
Ну чё, потянем дальше или ждём кого?
Не, мне кажется всё таки правильнее "часто посылать в одних и отправлять в других". Хотя...
13 Кеширование в HTTP
HTTP обычно используется в распределенных информационных системах,где работа может быть улучшена путем кеширования ответов.
Протокол HTTP/1.1 включает ряд элементов, предназначенных для улучшения, насколько это возможно, работы кеширования.
Поскольку эти элементы зависят от определённых аспектов протокола и взаимодействуют друг с другом, будет полезно описать основную схему кэширования HTTP отдельно от детального описания методов, заголовков, кодов ответов и т.д.
Кэширование было бы бесполезно, если бы оно значительно не увеличивало быстродействие.
Задача кэширования в HTTP/1.1 состоит в избежании необходимости слишком часто отсылать запросы и полные ответы.
В первом случае сокращается число запрос/ответов требуемых для многих операций, мы используем в этом случае "expiration" механизм(expiration-истечение срока)(см.главу13.2). Во втором случае сокращается требования к пропускной способности канала, мы используем в этом случае "validation" механизм(validation-подтверждение).(см.главу13.3)
Ну чё, потянем дальше или ждём кого?
Не, мне кажется всё таки правильнее "часто посылать в одних и отправлять в других". Хотя...
Но ведь как то не по-русски получается "часто посылать в одних и отправлять в других"... в каких таких одних, а тем более в других?
Может тогда так: Задача кэширования в HTTP/1.1 состоит в избежании необходимости в определённых случаях отсылать запросы и полные ответы.
Да, кстати сразу не заметил perfomance - это же производительность ин рашн :P
А значит
13 Кеширование в HTTP
HTTP обычно используется в распределенных информационных системах, где производительность может быть улучшена за счёт кеширования ответов.
Протокол HTTP/1.1 включает в себя ряд элементов, предназначенных для улучшения, насколько это возможно, работы кеширования.
Поскольку эти элементы зависят от определённых аспектов протокола и взаимодействуют друг с другом, будет полезно описать основную схему кэширования HTTP отдельно от детального описания методов, заголовков, кодов ответов и т.д.
Кэширование было бы бесполезно, если бы оно значительно не увеличивало быстродействие.
Задача кэширования в HTTP/1.1 состоит в избежании необходимости слишком часто отсылать запросы и полные ответы.
В первом случае сокращается число запрос/ответов требуемых для большинства операций, в этом случае мы используем "expiration" механизм(expiration-истечение срока)(см.главу13.2). Во втором случае сокращаются требования к пропускной способности канала, в этом случае мы используем "validation" механизм(validation-подтверждение).(см.главу13.3
Может тогда так: Задача кэширования в HTTP/1.1 состоит в избежании необходимости в определённых случаях отсылать запросы и полные ответы.
Да, кстати сразу не заметил perfomance - это же производительность ин рашн :P
А значит
13 Кеширование в HTTP
HTTP обычно используется в распределенных информационных системах, где производительность может быть улучшена за счёт кеширования ответов.
Протокол HTTP/1.1 включает в себя ряд элементов, предназначенных для улучшения, насколько это возможно, работы кеширования.
Поскольку эти элементы зависят от определённых аспектов протокола и взаимодействуют друг с другом, будет полезно описать основную схему кэширования HTTP отдельно от детального описания методов, заголовков, кодов ответов и т.д.
Кэширование было бы бесполезно, если бы оно значительно не увеличивало быстродействие.
Задача кэширования в HTTP/1.1 состоит в избежании необходимости слишком часто отсылать запросы и полные ответы.
В первом случае сокращается число запрос/ответов требуемых для большинства операций, в этом случае мы используем "expiration" механизм(expiration-истечение срока)(см.главу13.2). Во втором случае сокращаются требования к пропускной способности канала, в этом случае мы используем "validation" механизм(validation-подтверждение).(см.главу13.3
Здорово.Великолепно. :)
А скажи мне что ты про эту хрень думаешь:
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency.
Чо то я её в голове не могу уместить :(
А скажи мне что ты про эту хрень думаешь:
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency.
Чо то я её в голове не могу уместить :(
Требования производительности, доступности и возможности оффлайн операций, требуют отказаться от эффекта достигаемого за счёт семантической прозрачности.
я не уверен, что правильно перевожу disconnected operations, но что-то мне подсказывает, что это возможность производить какие-то операции не находясь в онлайне... как думаешь?
я не уверен, что правильно перевожу disconnected operations, но что-то мне подсказывает, что это возможность производить какие-то операции не находясь в онлайне... как думаешь?
Цитата:
Originally posted by man
я не уверен, что правильно перевожу disconnected operations, но что-то мне подсказывает, что это возможность производить какие-то операции не находясь в онлайне... как думаешь?
я не уверен, что правильно перевожу disconnected operations, но что-то мне подсказывает, что это возможность производить какие-то операции не находясь в онлайне... как думаешь?
Я думаю что имеются в виду не связанные друг с другом операции (disconnected-бессвязный), исходя из здравого смысла-HTTPпротокол передачи текста, нет онлайна-нет передачи. А споткнулся я на require us to be able to relax.Теперь вот как бы это в двух словах на великом изобразить?
Ну тогда всё вместе будет примерно так:
Требования производительности, доступности и возможности не связанных друг с другом операций, требуют отказаться от цели достигаемой семантической прозрачностью.
Требования производительности, доступности и возможности не связанных друг с другом операций, требуют отказаться от цели достигаемой семантической прозрачностью.
Цитата:
Originally posted by man
Ну тогда всё вместе будет примерно так:
Требования производительности, доступности и возможности не связанных друг с другом операций, требуют отказаться от цели достигаемой семантической прозрачностью.
Ну тогда всё вместе будет примерно так:
Требования производительности, доступности и возможности не связанных друг с другом операций, требуют отказаться от цели достигаемой семантической прозрачностью.
Только не отказаться, а сделать менее строгими.(relax)
Криво оно как то звучит.Что то я смысл фразы не выхватываю.Обидно, блин.Ты да я да мы с тобой. А пофигу, пробьёмся.
Значится так.
--Как обозвать не связанные друг с другом операции?
--Что значит сделать менее строгой цель?
Далее:
However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client.
Однако, поскольку непрозрачные операции могут запутать неопытных пользователей, и могут быть несовместимы с определенными серверными приложениями (например предназначенные для заказа товаров), протокол требует чтобы прозрачность была разрешена только для явно ???protocol-level??? запросов когда ???разрешено??? клиентом или сервером только с явным предупреждением конечного пользователя when relaxed by cache or client
Хе-х :)
Идея не плохая. Такая практика всегда полезна.
Я лично учусь в Англиской школе, да к тому же информатику, так что мне сам Бог велел такие документы разберать. Вот потренеруюсь. Хотя этот казёный язык меня коробит.
А на сщёт relax the goal я подумаю. мне кажется что это вроде
"отступить от цели". или зделать менее важной именно эту цель, второстепенной что ли.
Ну вообше как то каряво у меня получается, ладно подумаю.
Я лично учусь в Англиской школе, да к тому же информатику, так что мне сам Бог велел такие документы разберать. Вот потренеруюсь. Хотя этот казёный язык меня коробит.
А на сщёт relax the goal я подумаю. мне кажется что это вроде
"отступить от цели". или зделать менее важной именно эту цель, второстепенной что ли.
Ну вообше как то каряво у меня получается, ладно подумаю.
ещё одно замечание.
как то странно требования ... требуют
это всё одно что заявление заявляет...
или я не прав
как то странно требования ... требуют
это всё одно что заявление заявляет...
или я не прав
Народ! Всё гораздо проще ;)
relax the goal означает отказаться от цели
goal - это же цель.. по-моему всё очень логично, а вот замечание требования требуют - эт zatch ты верно подметил, но это дело поправимое... что ж жалуйте третий вариант:
Требования производительности, доступности и возможности не связанных друг с другом операций, заставляют отказаться от цели достигаемой за счёт семантической прозрачности, отсюда и прозрачные/непрозрачные операции
Что означает семантическая прозрачность? Может это понятие где-нибудь оговаривается? А если оговаривается, то что оно даёт, что от этого так жалко отказываться?
However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client.
------------------------------------------------------
Однако, поскольку непрозрачные операции могут запутать неопытных пользователей, и могут быть несовместимы с определенными серверными приложениями (например предназначенные для заказа товаров), ТО протокол требует чтобы прозрачность была выполнена только для явного запроса протокольного уровня, когда выполняется клиентом или исходным сервером, и только с явным предупрежением, когда выполняется клиентом или кешомм
-------------------------------------------------------
Не скажу, что это удобоваримая форма, но если честно я даже по английски не понимаю, что здесь имеется в виду. Явно подразумевается какой то подтекст. To relax operation я перевожу как выполнить операцию - расслабить, дать волю операции... как думаете.
Непрозрачные операции - млжет быть сложные, навёрнутые операции? Ведь по смыслу подходит...
relax the goal означает отказаться от цели
goal - это же цель.. по-моему всё очень логично, а вот замечание требования требуют - эт zatch ты верно подметил, но это дело поправимое... что ж жалуйте третий вариант:
Требования производительности, доступности и возможности не связанных друг с другом операций, заставляют отказаться от цели достигаемой за счёт семантической прозрачности, отсюда и прозрачные/непрозрачные операции
Что означает семантическая прозрачность? Может это понятие где-нибудь оговаривается? А если оговаривается, то что оно даёт, что от этого так жалко отказываться?
However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client.
------------------------------------------------------
Однако, поскольку непрозрачные операции могут запутать неопытных пользователей, и могут быть несовместимы с определенными серверными приложениями (например предназначенные для заказа товаров), ТО протокол требует чтобы прозрачность была выполнена только для явного запроса протокольного уровня, когда выполняется клиентом или исходным сервером, и только с явным предупрежением, когда выполняется клиентом или кешомм
-------------------------------------------------------
Не скажу, что это удобоваримая форма, но если честно я даже по английски не понимаю, что здесь имеется в виду. Явно подразумевается какой то подтекст. To relax operation я перевожу как выполнить операцию - расслабить, дать волю операции... как думаете.
Непрозрачные операции - млжет быть сложные, навёрнутые операции? Ведь по смыслу подходит...
Цитата:
Originally posted by man
Что означает семантическая прозрачность? Может это понятие где-нибудь оговаривается? А если оговаривается, то что оно даёт, что от этого так жалко отказываться?
Что означает семантическая прозрачность? Может это понятие где-нибудь оговаривается? А если оговаривается, то что оно даёт, что от этого так жалко отказываться?
Семантически прозрачный (semantically transparent)
Говорят, что кэш ведет себя "семантически прозрачным" образом в отношении специфического ответа, когда использование кэша не влияет ни на клиента запроса, ни на первоначальный сервер, но повышает эффективность. Когда кэш семантически прозрачен, клиент получает точно такой же ответ (за исключением промежуточных (hop-by-hop) заголовков), который получил бы, запрашивая непосредственно первоначальный сервер, а не кэш.
Это из того неполного перевода который мы пытаемся сделать полным.Определено в самом начале.
И следующее:
Therefore, the HTTP/1.1 protocol provides these important elements:
1 Protocol features that provide full semantic transparency when this is required by all parties.
2 Protocol features that allow an origin server or user agent to explicitly request and control non-transparent operation.
3 Protocol features that allow a cache to attach warnings to
responses that do not preserve the requested approximation of semantic transparency.
Поэтому протокол HTTP/1.1 предоставляет эти важные элементы:
-1. Особенности протокола, которые предоставляют полную семантическую прозрачность когда это требуется всем участникам(сторонам)
-2. Особенности протокола, которые позволяют серверу или агенту пользователя явно запрашивать и контролировать непрозрачные операции.
-3. Особенности протокола, которые позволяют a cache to attach warnings на ответы, которые не соблюдают(не придерживаются)требуемое приближение семантической прозрачности.
И из этой главы осталось:
A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency.
Note: The server, cache, or client implementer may be faced with design decisions not explicitly discussed in this specification. If a decision may affect semantic transparency, the implementer ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency.
Ну как , может добьём уже и пообсуждаем точные формулировки.
P.s. Да и вот ещё:Про пользователя забыли :)
However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client.
------------------------------------------------------
Однако, поскольку непрозрачные операции могут запутать неопытных пользователей, и могут быть несовместимы с определенными серверными приложениями (например предназначенные для заказа товаров), ТО протокол требует чтобы прозрачность была выполнена только для явного запроса протокольного уровня, когда выполняется клиентом или исходным сервером, и только с явным предупрежением, когда выполняется клиентом или кешомм
-------------------------------------------------------
Однако, поскольку непрозрачные операции могут запутать неопытных пользователей, и могут быть несовместимы с определенными серверными приложениями (например предназначенные для заказа товаров), ТО протокол требует чтобы прозрачность была выполнена только для явного запроса протокольного уровня, когда выполняется клиентом или исходным сервером, и только с явным предупрежением конечного пользователя, когда выполняется клиентом или кешом.
А так вроде ничего, чой то вырисовывается.
Так. 'Я бы предложил to relax the goal перевести как "смягчить требования".' Это на lingvo.ru ответили. Вроде как более грамотно звучит.Получаем:
Требования производительности, доступности и возможности не связанных друг с другом операций, требуют смягчить требования семантической прозрачности.
Называется "умри тафтолог".Кто какие варианты предложит.
Цитата:
Originally posted by chigevara
P.s. Да и вот ещё:Про пользователя забыли :)
-------------------------------------------------------
P.s. Да и вот ещё:Про пользователя забыли :)
-------------------------------------------------------
Нихрена!!!
Однако, поскольку непрозрачные операции могут запутать неопытных пользователей, и могут быть несовместимы с определенными серверными приложениями (например предназначенные для заказа товаров), ТО протокол требует чтобы прозрачность была разрешена только явным запросом протокольного уровня, когда разрешено клиентом или исходным сервером, и только с явным предупреждением конечного пользователя, когда разрешено клиентом или кешом.
Помоему так.(Тихо сам с собою я веду беседу :) )
Цитата:
В общем вот такая вот петрушка
13 Caching in HTTP
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Because these elements are inextricable from other aspects of the protocol, and because they interact with each other, it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.
Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see section 13.3).
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client
Therefore, the HTTP/1.1 protocol provides these important elements:
1 Protocol features that provide full semantic transparency when this is required by all parties.
2 Protocol features that allow an origin server or user agent to explicitly request and control non-transparent operation.
3 Protocol features that allow a cache to attach warnings to responses that do not preserve the requested approximation of semantic transparency.
A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency.
Note: The server, cache, or client implementer may be faced with design decisions not explicitly discussed in this specification. If a decision may affect semantic transparency, the implementer ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency.
13 Caching in HTTP
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Because these elements are inextricable from other aspects of the protocol, and because they interact with each other, it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.
Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see section 13.3).
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed only by an explicit protocol-level request when relaxed by client or origin server only with an explicit warning to the end user when relaxed by cache or client
Therefore, the HTTP/1.1 protocol provides these important elements:
1 Protocol features that provide full semantic transparency when this is required by all parties.
2 Protocol features that allow an origin server or user agent to explicitly request and control non-transparent operation.
3 Protocol features that allow a cache to attach warnings to responses that do not preserve the requested approximation of semantic transparency.
A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency.
Note: The server, cache, or client implementer may be faced with design decisions not explicitly discussed in this specification. If a decision may affect semantic transparency, the implementer ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency.
13 Кеширование в HTTP
HTTP обычно используется в распределенных информационных системах, где производительность может быть улучшена за счёт кэширования ответов.
Протокол HTTP/1.1 включает в себя ряд элементов, предназначенных для улучшения, насколько это возможно, работы кэширования.
Поскольку эти элементы зависят от определённых аспектов протокола и взаимодействуют друг с другом, будет полезно описать основную схему кэширования HTTP отдельно от детального описания методов, заголовков, кодов ответов и т.д.
Кэширование было бы бесполезно, если бы оно значительно не увеличивало быстродействие.
Задача кэширования в HTTP/1.1 состоит в избежании необходимости слишком часто отсылать запросы и полные ответы.
В первом случае сокращается число запрос/ответов требуемых для большинства операций, в этом случае мы используем "expiration" механизм(expiration-истечение срока)(см.главу13.2). Во втором случае сокращаются требования к пропускной способности канала, в этом случае мы используем "validation" механизм(validation-подтверждение).(см.главу13.3)
Соображения производительности, доступности и возможности различных операций вынуждают смягчить требования семантической прозрачности.
Однако, поскольку непрозрачные операции могут запутать неопытных пользователей, и могут быть несовместимы с определенными серверными приложениями (например предназначенными для заказа товаров), то протокол требует чтобы прозрачность была разрешена только явным запросом протокольного уровня, когда разрешено клиентом или исходным сервером, и только с явным предупреждением конечного пользователя, когда разрешено кешом или клиентом.
Поэтому протокол HTTP/1.1 предоставляет следующие важные элементы:
-1. Особенности протокола, которые предоставляют полную семантическую прозрачность когда это требуется всем участникам(сторонам)
-2. Особенности протокола, которые позволяют серверу или агенту пользователя явно запрашивать и контролировать непрозрачные операции.
-3. Особенности протокола, которые позволяют a cache to attach warnings на ответы, которые не соблюдают(не придерживаются)требуемое приближение семантической прозрачности.
Основным принципом является возможность для клиентов обнаружить любое потенциальное ослабление семантической прозрачности.
Примечание:
Реализация сервера, кэша, или клиента может быть разработана с решениями, не обсуждёнными явно в этой спецификации.
Если решение может затрагивать семантическую прозрачность, реализация должна выводить ошибку стороне, поддерживающей прозрачность, если тщательный и полный анализ не обещает значительной выгоды в нарушении прозрачности.
Кто что мыслит?
Ну ты мощно забомбил! :) Надо почитать вникнуть. Согласен насчёт relax the goal, логика есть... у меня завтра или уже сегодня будет английский...надо бы узнать у профа действительно ли это так. Она для правительства переводы в Страсбурге делает...круто, да?
Но пасаран!
Но пасаран!
Цитата:
Originally posted by man
Она для правительства переводы в Страсбурге делает...круто, да?
Она для правительства переводы в Страсбурге делает...круто, да?
Круто! Ей бы не в Страсбурге а на codenete: цены б ей не было ;)