+  HandyCache форум
|-+  Главная категория» Дополнения, плагины» GE.lua - расширение HC для кэширование Google Earth
Имя пользователя:
Пароль:
Страниц: 1 ... 5 6 [7] 8 9   Вниз
  Отправить эту тему    Печать  
Автор Тема: GE.lua - расширение HC для кэширование Google Earth  (Прочитано 98545 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Михаил
Модератор
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #120 : 25 июня 2009, 16:48:55 »

на кого ориентироваться?
На того, кому отвечаем. Он должен нас понять.
Цитировать
Не проще в ответе явно написать?
Дело не в простоте. Пользователь формирует с помощью скрипта валидный с точки зрения стандарта HTTP ответ. И вправе быть уверенным в том, что НС тоже действует по стандарту при отправке такого ответа клиенту.
В нашем случае клиент HTTP 1.0 (Гугл) получает от НС ответ без заголовка Connection и по логике этой версии протокола бремя закрытия соединения оставляет серверу (HC).
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #121 : 25 июня 2009, 17:14:02 »

Цитировать
Дело не в простоте. Пользователь формирует с помощью скрипта валидный с точки зрения стандарта HTTP ответ. И вправе быть уверенным в том, что НС тоже действует по стандарту при отправке такого ответа клиенту.
В нашем случае клиент HTTP 1.0 (Гугл) получает от НС ответ без заголовка Connection и по логике этой версии протокола бремя закрытия соединения оставляет серверу (HC).
Я читал в стандарте, что если http 1.0 клиент опускает в заголовке поле Connection, то клиент рассматривает соединение как Непостоянное. Но я нигде не читал, что СЕРВЕР отвечая http 1.0  клиенту может опустить в ответе поле Connection и это будет равносильно наличию Connection: close. Если я это упустил, дай цитату. Я же вижу вот, что
Цитировать
8.1.2.1 Negotiation
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it SHOULD send a Connection header including the connection-token close.

An HTTP/1.1 client MAY expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than that request, it SHOULD send a Connection header including the connection-token close.

If either the client or the server sends the close token in the Connection header, that request becomes the last one for the connection.

Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See section 19.6.2 for more information on backward compatibility with HTTP/1.0 clients.
Я не против сделать по стандарту. Просто я нигде не нахожу исчерпывающего ответа на возникающие у меня вопросы, слишком тут все запутано и по этой причине чревато ошибками. Считаю, что явное указание желаемого поведения в заголовке позволит избежать разночтений и сделать работу надежной.
Сообщить модератору   Записан
Михаил
Модератор
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #122 : 25 июня 2009, 17:55:50 »

Цитировать
я нигде не читал, что СЕРВЕР отвечая http 1.0  клиенту может опустить в ответе поле Connection и это будет равносильно наличию Connection: close.
Для "чистого" клиента http 1.0 заголовок Connection ничего не значит. В этой версии протокола такого заголовка не предусмотрено.
Цитировать
Считаю, что явное указание желаемого поведения в заголовке позволит избежать разночтений и сделать работу надежной.
Если в ответе пишем Connection: close, НС закроет соединение сам или будет ждать этого от клиента?
Цитировать
дай цитату
RFC 1945, регламентирующий http 1.0:
Цитировать
Except for experimental applications, current practice requires that
   the connection be established by the client prior to each request and
   closed by the server after sending the response.
Видимо, этой логики придерживается Гугл, выступая в роли клиента http 1.0 при отсутствии в ответе заголовка Connection.
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #123 : 25 июня 2009, 18:15:32 »

Цитировать
Если в ответе пишем Connection: close, НС закроет соединение сам или будет ждать этого от клиента?
Закроет сам.
Цитировать
Видимо, этой логики придерживается Гугл, выступая в роли клиента http 1.0 при отсутствии в ответе заголовка Connection.
Я сам не проверял, но Parasite пишет же, что
Цитировать
Клиент всегда просит 1.1\KeepAlive.
Мало того, что 1.1, так еще и KeepAlive.
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #124 : 25 июня 2009, 18:26:45 »

Цитировать
я нигде не читал, что СЕРВЕР отвечая http 1.0  клиенту может опустить в ответе поле Connection и это будет равносильно наличию Connection: close.
Для "чистого" клиента http 1.0 заголовок Connection ничего не значит.
Дело в том, что ГЕ - клиент 1.1 (коль скоро просит этого), но в его ПОЛНОЙ поддержке 1.1 (как и 1.0) лично я сильно сомневаюсь. Ему это просто не нужно - это попсовая программка,  изначально предназначенная для работы с ОДНИМ конкретно взятым своим сервером, и рамки "стандарта" оговариваются только фактом "работает\не работает именно эта связка". Какую-то меру совместимости ГЕ поддерживает сугубо для беспрепятственного прохождения своего трафика по всем хопам, и имхо не более того.
Лично я бы не ждал от него идеального соответствия RFC именно по этому поводу. Предположительно, конечно. Сказать же точнее - это надо иметь сорцы на сам ГЕ и на его сервер, чего разумеется у нас нет и не будет. Грустный
Добавлено: 25 Июня 2009, 18:20:53

Я сам не проверял, но Parasite пишет же, что
Цитировать
Клиент всегда просит 1.1\KeepAlive.
Мало того, что 1.1, так еще и KeepAlive.
Да. В аттаче - классический заголовок классического ГЕ на прямом коннекте.


* Clipboard01.gif (25.46 Кб, 1302x224 - просмотрено 49 раз.)
Сообщить модератору   Записан
Михаил
Модератор
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #125 : 25 июня 2009, 19:03:57 »

Гугл зависаниями дал раскопать, что клиент 1.0 не берет на себя бремени закрытия соединения. Поэтому если отвечаем клиенту 1.0, и ответ не содержит явную попытку сохранить соединение в виде (Proxy-)Connection: keep-alive, то НС должен закрыть соединение после передачи ответа. Иначе разработчик скрипта, сформировав правильный с точки зрения стандарта ответ, рискует получить зависание.
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #126 : 25 июня 2009, 20:19:13 »

Гугл зависаниями дал раскопать, что клиент 1.0 не берет на себя бремени закрытия соединения. Поэтому если отвечаем клиенту 1.0, и ответ не содержит явную попытку сохранить соединение в виде (Proxy-)Connection: keep-alive, то НС должен закрыть соединение после передачи ответа. Иначе разработчик скрипта, сформировав правильный с точки зрения стандарта ответ, рискует получить зависание.
Отсюда вопрос ребром: стоит ли редактировать ВЕСЬ (как сущность) HC для нужд одной-единственной не самой серьезной программы - либо же достаточно подредактировать скрипт, напрямую давая понять что делать с соединением?

Лично я за второй вариант. Проблемы и недоработки ГЕ не обязаны влиять на весь HC, имхо - коль скоро HC делается не только под ГЕ. Для ГЕ достаточно будет и скрипта, по-моему - в нем и без этого багов немало, под каждый HC менять не будем же...
Сообщить модератору   Записан
Михаил
Модератор
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #127 : 25 июня 2009, 22:55:40 »

Проблема другая: обнаружена ошибка НС. О Гугле и скрипте GE.lua вопрос уже несколько дней не стоит - там все решено и работает. Пишу в этой теме только "по инерции" из-за того, что здесь была обнаружена эта ошибка. Касается она работы с любым http 1.0 клиентом. Возьми IE - зависнет и он, возьми другой клиент - может зависнуть и он...
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #128 : 26 июня 2009, 13:01:15 »

здесь была обнаружена эта ошибка. Касается она работы с любым http 1.0 клиентом. Возьми IE - зависнет и он, возьми другой клиент - может зависнуть и он...
Понятно. Тогда, разумеется, надо решать.

Автору HC: ну когда же, КОГДА появится желаемая возможность сортировки скриптом по папкам кэша? Улыбка
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #129 : 26 июня 2009, 13:07:28 »

Цитировать
ну когда же, КОГДА появится желаемая возможность сортировки скриптом по папкам кэша?
Такая версия уже тестируется, доработаю описание и дам тебе потестировать. А ты сам попробуешь скрипт написать?
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #130 : 26 июня 2009, 14:03:37 »

Такая версия уже тестируется, доработаю описание и дам тебе потестировать. А ты сам попробуешь скрипт написать?
Постараюсь, хотя с LUA знаком на уровне "Чуваки, гля какую хрень тут в инете откопал...!" Улыбка

Кстати, почему именно LUA? Посему не, например, Perl с его вкусными регэкспами и мощью по обработке строк (самое оно для HC, имхо - с его массовыми разборами\заменами УРЛов)? Он тоже бесплатный.
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #131 : 26 июня 2009, 15:14:18 »

Lua показался мне наиболее подходящим для возложенных на него задач в контексте его использования в НС. Очень легкий в изучении язык, позволяет сразу после знакомства писать короткие скрипты, что чаще всего и нужно для НС. В то же время, если надо, можно копнуть глубже и найти средства для решения почти любой задачи (в том числе и PCRE).
Тут более подробно по этому вопросу http://lua-users.org/wiki/LuaVersusPerl
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #132 : 26 июня 2009, 20:14:41 »

Lua показался мне наиболее подходящим для возложенных на него задач в контексте его использования в НС. Очень легкий в изучении язык, позволяет сразу после знакомства писать короткие скрипты, что чаще всего и нужно для НС. В то же время, если надо, можно копнуть глубже и найти средства для решения почти любой задачи (в том числе и PCRE).
Тут более подробно по этому вопросу http://lua-users.org/wiki/LuaVersusPerl
Понятно.

А в какой мере HC поддерживает язык LUA? В полной, или с какими-то ограничениями\кастрациями\обрезками функционала? По вышеприведенной ссылке невнятно упоминалось, что есть возможность вызова перловых скриптов из-под LUA (and vice versa):
Цитировать
There is an implementation of Lua on Parrot. Inline::Lua [44] and [Lux] (though not recently maintained) embed Lua in Perl. There is a way to call Perl from Lua [45].
(#ref пока не читал - чуть позже).

Значит ли это, что я теоретически могу подключить свои перловые скрипты в HC - и они будут работать в своем полном перловом обьеме со всеми стандартными фичами, багами и уже перловыми модулями и расширениями себя любимого? Улыбка  Тогда бы HC стала (для меня) действительно универсальной, и без необходимости изучения экзотики в виде LUA.
Как считаете?
Сообщить модератору   Записан
mai62
Автор HC
*****

Репутация: +226/-4
Offline Offline

Сообщений: 6383


« Ответ #133 : 26 июня 2009, 20:22:40 »

НС не ограничивает возможностей lua. Пробуй.
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #134 : 04 июля 2009, 07:12:52 »

Цитировать
ну когда же, КОГДА появится желаемая возможность сортировки скриптом по папкам кэша?
Такая версия уже тестируется, доработаю описание и дам тебе потестировать. А ты сам попробуешь скрипт написать?
Господа, помогите пожалуйста перевести  следующий алгоритм в LUA? Что-то у меня сложно всё с ним... Грустный

Код:
function GENameStringToXY(NAME:string;Level:byte):TPoint;
var i:byte;
begin
     // переменная NAME - строка с цифро-именем: NAME='01230123'
     // Level - зум - длина строки NAME

     result.X:=0;  // инициализация X,Y и если Level=1 то и
     result.Y:=0;  // ответ функции

     for i:=2 to Level do // цикл от 2 до Level
     begin
          result.X:=result.X*2; // ответ увеличиваем в 2 раза
          result.Y:=result.Y*2;

          case NAME[i] of
          '0': inc(result.Y); // к Y прибавляем 1 если символ '0'

          '1': begin // если символ '1' и к X и к Y прибавляем 1
                  inc(result.X);
                  inc(result.Y);
               end;

          '2': inc(result.X);

          end;
     end;
end;
Спасибо.
Сообщить модератору   Записан
Михаил
Модератор
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #135 : 04 июля 2009, 07:42:09 »

Будет как-то так:
Цитировать
function GENameStringToXY(NAME, Level)
     -- переменная NAME - строка с цифро-именем: NAME='01230123'
     -- Level - зум - длина строки NAME

     local X = 0  -- инициализация X,Y и если Level=1 то и
     local Y = 0  -- ответ функции

     for i=2,Level do -- цикл от 2 до Level
          X = X*2      -- ответ увеличиваем в 2 раза
          Y = Y*2

          local ch = NAME:sub(i,i)
          if ch == '0' then
               Y = Y+1     -- к Y прибавляем 1 если символ '0'
          elseif ch == '1' then
               X = X+1     -- если символ '1' и к X и к Y прибавляем 1
               Y = Y+1
          elseif ch == '2' then
               X = X+1
          end
     end
     return X, Y
end
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #136 : 04 июля 2009, 21:17:30 »

Будет как-то так:
О, спасибо! Попробую.

И последний (надеюсь) вопрос: как в LUA из filename, например, f1c-xxxxxxxx.yyy.zzz выпарсить соответственные числовые параметры в переменные X, Y и Z для дальнейшего пересчета?
Пробовал по-перловскому, через регекспы - еррорит и  не исполняет уже весь скрипт...Грустный

PS: это все в тему сортировки тайлов ГЕ, так что просьба не считать за оффтоп.
Спасибо.
Сообщить модератору   Записан
Михаил
Модератор
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #137 : 04 июля 2009, 21:38:28 »

Можно попробовать так:
Цитировать
local X,Y,Z = filename:match('%w+%-(%d+)%.(%d+)%.(%d+)')
Сообщить модератору   Записан
Parasite
Пользователь
**

Репутация: +1/-0
Offline Offline

Сообщений: 66



« Ответ #138 : 05 июля 2009, 20:54:04 »

Никак не получается переназначить имя в кэше...

Код:
    -- если запрошенный файл не составной, то не обновляем его
    -- hc.put_to_log('+++++++++++++ ', URLTail, ' +++++++++++')
    if not URLTail:find('+', 1, true) then
        get_cache_name(URLtail)
        hc.action = 'dont_update'
        return
    end

............

function get_cache_name(URLtail)
local Base_Path= '1'
        hc.cache_file_name= Base_Path..'\\'..URLtail
        hc.monitor_string = 'Processed!'
end
...но при получении единичного файла - он кладется как всегда (во ./flatfile^/q2-030122322221-q.206 например, а не в ./1/q2-030122322221-q.206).
Что я не так делаю? Грустный
Сообщить модератору   Записан
Михаил
Модератор
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #139 : 05 июля 2009, 23:29:18 »

hc.cache_file_name в этом контексте только для чтения, поэтому присваивание ничего не делает.

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

* Google Earth.rar (3.25 Кб - загружено 40 раз.)
Сообщить модератору   Записан
Страниц: 1 ... 5 6 [7] 8 9   Вверх
  Отправить эту тему    Печать  

 
Перейти в: