автоматический редирект на https<->http

Маленький пример кода для перенаправления:

     $redirect_needed = false; 
    /*
     * какое-то очень умное правило определения важности
     * шифрования данной страницы 
     */
    if (!isset($_SERVER['HTTPS']) && $redirect_needed) { 
      header('Location: https://'.$_SERVER['SERVER_NAME'].$_SERVER['PHP_SELF']); 
      die(); 
    } 
    if (isset($_SERVER['HTTPS']) && !$redirect_needed) { 
      header('Location: http://'.$_SERVER['SERVER_NAME'].$_SERVER['PHP_SELF']); 
      die(); 
    }

Ошибка ли?

Обнаружил интересную особенность в обработке анимации(gif) в gtk+. Непосредственно ошибку обнаружил не я, но я все таки решил проверить, можно ее повторить без лишнего кода. Оказалось да - но распространяется она не только на случай, когда файл загружается частями gdk_pixbuf_loader_write и потом показывается анимация (gdk_pixbuf_loader_get_animation + gdk_pixbuf_animation_get_iter), но даже если загрузить анимацию сразу через gtk_image_new_from_file. В любом случае используется до 1GB памяти - что не очень хорошо для 6MB файла, да и вообще плохо. 

Если верить документации на gdk_pixbuf_animation_get_iter - то библотека сама контолирует выделение pixbuf и после сдвига его использовать нельзя. Я думал что после загрузки через gdk_pixbuf_loader - создается копия данных и как только количество этих данных становиться больше чем нужно, для минимального отображение, посылается сигнал на прорисовку - что в принципе подтвердилось, так как если брать статическую картинку(gdk-pixbuf-animation-get-static-image), то затраты памяти значительно меньше. Далее я думал, что gdk_pixbuf_animation - при создании создает только 1 кадр, и при запросе на сдвиг времени выдает следующий по порядку(пропуская лишние, если нужно) и удаляет предыдущий копию. Но похоже это не так так как если самому вызывать очитку отображенного кадра(unref) при удалении обьекта анимации создается сообщения о повторном удалении обьектов. Думаю создаються все кадра и не удаляются.

И ошибка или так задумано?

Сравнение скорости прорисовки карт(gmap, openlayers).

Маленькое сравнение библиотек для работы с картами (в скобках более слабый компьютер):

1. gmap v3 - 7,186(13) секунд;
2. gmap v2 - 20,541(34) секунд;
3. openlayers - 6,181(7) секунд.

Условия:

• Прорисовывается список стран используя изначально разобранный kml, для уравновешивания условий прорисовки (Gmap - для прорисовки kml используется разбор на уровне сервера с возвратом обратно только готового изображения);
• Запускается по нажатию на start, и до момента нажатия stop. Почему не автоматом? Карта может прорисовываться асинхронно, а так точно можно отследить, хоть и не с абсолютной точностью, момент когда по мнению пользователя все прорисовано;
• Подсчет времени начинается после разбора, результаты должны быть более-менее реалистичными;
• Вариант прорисовки через canvas для openlayers не участвовал в сравнении, так как сильно проигрывал стандартному варианту;
• Использовался ff 3.6.3(linux).

Если кто-то найдет ошибки в коде прорисовки или способы ускорения буду рад обсудить.

Hybrid graphics and .34

Поставил себе .34 ядро в Ubuntu, в нем поддержка Hybrid graphics(switcheroo), оказалась отключена (файл для управления не создавался). Пересобирать ядро, как то желания не появилось, решил пока подождать выхода .34.1 и посмотреть на результаты в Lunar. В этом дистрибутиве появляются ядра в основном только после выхода первого багфикса, что в принципе и правильно.

В общем результаты: самый честный счетчик попугаев glxgears подрос до 3278 frames in 5.0 seconds(OpenGL renderer string: Mesa DRI R600 (RS780 9612) 20090101 TCL DRI2, 1.5 Mesa 7.7.1), в втором кубе вода стала прозрачной, но деревья стали выглядеть несколько странно в виде рубленных текстур.

Формирование pdf из js

Обнаружилась интересная библиотека jspdf - позволяющая создавать простейшие pdf из js. Она основана на коде(скорее принципах и как пример) fpdf. Позволяет менять размер шрифта и размещать текст на странице - pdf возвращается как datauri, отлично работает в linux, но в windows есть несколько проблемок: ie не понимает datauri ни в каких формах, кроме как встроенное в страницу изображение, firefox при установленных обработчиках pdf(например: acrobat reader) происходит переход на этот url и показывается черный экран вместо контента страницы, иначе предложение загрузить. Это решаемо достаточно просто контент отправляется обратно на сервер как параметр POST, в ответ возвращается уже как контент с типом pdf - и все нормально работает.

P.S.: Я немного улучшил эту библиотеку добавив смену цвета шрифтов, поддерживается градации серого и полная RGB палитра.

gtkhtml

Прогресс добавления поддержки css:

libxml2

Может изменять кодировку поэтому дерево всегда приходит в utf8. То есть она частично снимает проблему конвертации - нужна только в ответном запросе.

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

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

Сама библиотека:

Отрисовка дерева строиться на собственном виде дерева элементов - поэтому

четкого преобразования полученного DOM дерева  в дерево элементов один в один получить нельзя. Сейчас с моими изменениями пытаемся реализовать почти преобразование один в один - поэтому многие вещи отображаются не корректно. Например картинки - если они находятся на более чем одном уровне вложенности их не показывает, так как описания потока отображения(clue) - поддерживает только определенный вид вложенности - и определенные комбинации не могут быть отработаны так как код реализации выравнивания и раз размещения реализованы не для всех потоков(точнее по части функционала в каждом) .

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

Сейчас основной различие - применены все мои изменения для исправления мелких ошибок функциональности(выделены как патчи в bugzilla): исправления относительных путей, поддержка datauri и мелкие исправление в makefile. И не выделенные в качестве изменений: зависимости от гнома при компиляции(gnome-common,gconf), удален парсер html и рекурсивная обработка дерева.

В общем пока планирую - вернуться к не рекурсивному обходу дерева(стандартным старым функциям) и попытаться запостить патч в стандартную ветвь.

Стоит прочитать.....

Недавно дочитал книгу о физике Ричарде Ф.Фейнмане.'Вы, конечно, шутите, мистер Фейнман!' - очень веселая и интересная книга, рекомендовал бы в любом случая прочитать. Физика(и вообще наука) в книге упоминается очень вскользь и очень простыми для понимания фразами, можно читать книгу как собрание интересных историй из жизни.