Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 114
Имхо пора уже встраивать в ось подобные решение, как это сделано в Линуксе.
Чтоб автоматом обновляло флеш-плеер, браузер, java, js-библиотеки и прочие вещи для нормального отображения сайтов. И будет пользователю счастье :)
Чтоб автоматом обновляло флеш-плеер, браузер, java, js-библиотеки и прочие вещи для нормального отображения сайтов. И будет пользователю счастье :)
зачем?
ни к чему неподконтрольные обновления. если мне нужно - я сам обновлю или, в крайнем случае, поставлю на автообновление
ни к чему неподконтрольные обновления. если мне нужно - я сам обновлю или, в крайнем случае, поставлю на автообновление
Да не об обновлении как таковом речь, суть просто в том, что б популярные библиотеки уже лежали на клиенте, а не грузились по многу раз.
Все не настолько просто, как кажется.
Во первых - кто возьмется разработать адекватную методику и осуществить ранжирование по популярности библиотек? Элементарный соцопрос по большому счету - пыль в глаза, и на аргументацию для затраты денег вряд ли потянет.
Полагаю, подобный вопрос уже рассматривался разработчиками. Если подумать, то у любого программного продукта вполне достаточно критериев, которые могут быть оценены юзером как негативно так и позитивно. Так зачем же добавлять еще один, который притом был бы оценен многими негативно, ибо удовлетворить каждого юзера, к сожалению, достаточно сложно
Во первых - кто возьмется разработать адекватную методику и осуществить ранжирование по популярности библиотек? Элементарный соцопрос по большому счету - пыль в глаза, и на аргументацию для затраты денег вряд ли потянет.
Полагаю, подобный вопрос уже рассматривался разработчиками. Если подумать, то у любого программного продукта вполне достаточно критериев, которые могут быть оценены юзером как негативно так и позитивно. Так зачем же добавлять еще один, который притом был бы оценен многими негативно, ибо удовлетворить каждого юзера, к сожалению, достаточно сложно
вы говорите как продвинутый юзер, у которого и так стоят все обновления...
Если дело пойдет, то я лично буду писать разработчиками про SVN.
Давайте спустимся в мир реалий броузерного рынка. От момента появления идеи и до момента когда разработчики сайтов смогуть использовать новую технологию пройдёт как минимум 5 лет. Нам бы сейчас хотя бы человеческой поддержки CSS2 во всех броузерах.
Сама идея конечно интересна, но боюсь, что в жизнь воплотить её получиться не скоро.
Сама идея конечно интересна, но боюсь, что в жизнь воплотить её получиться не скоро.
основным тормозом является ИЕ.
Файрфокс и Опера скоро введут css3, как мне кажется.
Файрфокс и Опера скоро введут css3, как мне кажется.
Тут только два варианта. 1. Все уйдут от ИЕ. 2. Microsoft возмётся за ум и начнет активно поддерживать Internet Explorer. Конечно шансов, что какой либо из этих двух вариантов воплотится в жизнь очень мало.
А пока технология не работает в IE мы её использовать по понятным причинам не можем.
А пока технология не работает в IE мы её использовать по понятным причинам не можем.
надеюсь что выпуск 7-ого ИЕ и стал развитием второго сценария.
ага. Теперь приходится под виртуальной машиной загружаться чтоб посмотреть как в 6м все смотрится (правда ис-под линуха две виртуалки для 6 и 7 надо, но это уже такое).
имхо, шаг сделан настолько убогий что местами больше навредил нежели помог
имхо, шаг сделан настолько убогий что местами больше навредил нежели помог
IE 6 и 7 уже давно стоят рядом с друг другом, поэтому ставь их оба на одну виртуальную и не парься.
google: IE7 standalone
google: IE7 standalone
Да. и ещё, ie6 давно уже хорошо себя чувствует под wine.
google: ies4linux
google: ies4linux
Про IE7 standalone знаю, мне не понравилось, не помню уже почему.
А вот это не поможет ли?
http://tredosoft.com/Multiple_IE
http://tredosoft.com/Multiple_IE
Сомневаюсь я, что ИЕ начнут активно поддерживать. Вы только вдумайтесь, на днях взял лицензионную Win XP, build date: 13.06.2007. Вроде бы как совсем свеженькая. Но у встроенного ИЕ6 стоит дата 17.08.2004.
а как вы определили build date?
На коробке написано.
можете сфоткать?
Пожалуйста: http://domanet.org.ua/files/winbn.jpg
build date: 13.06.2007. Вроде бы как совсем свеженькая. Но у встроенного ИЕ6 стоит дата 17.08.2004
Если вы имели ввиду build date ЯДРА, то на коробке это не оно :)
Build date ядра Windows XP август-сентябрь 2001 года, а потом (ВОЗМОЖНО!) само ядро уже корректировалось с помощью service pack-ов.
А так, да, совпадение интересное :)
А какая разница, какая дата билда у программы, которая должна выводить на экран N панелей, причем все не из своих ресурсов и один прямоугольник с неизвестным для программы содержимым?
За корявую картинку отвечает не "iexplore.exe", а великий и ужасный движок Trident, который в винде используется для отображения почти всего, что есть на экране. Они настолько его "под себя" сделали, что выпрямить это убожество под стандарты уже нереально. Поэтому ИЕ никогда не будет поддерживать стандарты. ВООБЩЕ НИКОГДА.
За корявую картинку отвечает не "iexplore.exe", а великий и ужасный движок Trident, который в винде используется для отображения почти всего, что есть на экране. Они настолько его "под себя" сделали, что выпрямить это убожество под стандарты уже нереально. Поэтому ИЕ никогда не будет поддерживать стандарты. ВООБЩЕ НИКОГДА.
Тут скорее всего просто дата последнего обновления (последнего встроенного патча в систему)
А вот про IE это отдельная тема :)
А вот про IE это отдельная тема :)
Смотрите, я порсто предлагаю сделать такую фитчу в FF. КТо захочет - напишет плагины и для IE. Этот топик скорее даже proof of concept.
С первого взгляда идея действительно неплохая. Но:
1. При обновлении библиотек может возникнуть проблема совместимости со старыми версиями, тем самым к различиям между бразуерами добавятся еще и различия в библиотеках.
2. Кто будет определять избранные библиотеки? Простой подсчет распространности той или иной библиотеки не факт, что будет правильным.
3. ИЕ, без комментариев.
Минусов могу привести еще несколько, но я думаю, ход мыслей и так уже понятен.
1. При обновлении библиотек может возникнуть проблема совместимости со старыми версиями, тем самым к различиям между бразуерами добавятся еще и различия в библиотеках.
2. Кто будет определять избранные библиотеки? Простой подсчет распространности той или иной библиотеки не факт, что будет правильным.
3. ИЕ, без комментариев.
Минусов могу привести еще несколько, но я думаю, ход мыслей и так уже понятен.
А расширение может хранить несколько версий, он смотрит какая заявлена в странице, и ту и использует. Без загрузки. А если версия не заявлена - пользует последнюю.
Получим ад библиотек аналогичный аду DLL
Я говорю пока про экстеншин для FF. Тоесть «никто-никого-ни-за-что-не-тянет». Хотите - ставьте, не хотите - не надо! Включить туда JQuery, prototype, Dojo Toolkit, YUI, ExtJS, MochiKit, Mootools и, думаю, хватит + возможность юзеру самому добавлять библиотеки и указывать их CVS.
А может не стоит ломиться в открытую дверь ? Составить каталог полезных библиотек, выложить их manifest'ы на надёжный хостинг (хотя бы на GooglePages), и всё: кто хочет - может пользовать, кто не хочет - может не пользовать. Подробнее здесь: http://code.google.com/apis/gears/api_localserver.html#ManagedResourceStore
Я понимаю что изобрести собственный велосипед прикольнее и в иделе лучше бы этим занималась OS вообще, но... вам шашечки или ехать ?
P.S. Заодно можно иметь отдельно "самую последную версию" (для разработки) и "stable version" (production) библиотек...
Я понимаю что изобрести собственный велосипед прикольнее и в иделе лучше бы этим занималась OS вообще, но... вам шашечки или ехать ?
P.S. Заодно можно иметь отдельно "самую последную версию" (для разработки) и "stable version" (production) библиотек...
ПС: там же в конце написано как избежать ада:
Операционная система должна поставляться совместно с пакетным менеджментом, чтобы иметь возможность прослеживать все взаимозависимости DLL, при этом использование пакетного менеджмента должно поощряться, а индивидуальная инсталляция DLL по возможности отвергаться.. В переносе на нашу проблему это как раз то, что я хочу сделать.
Ну дык... сделать зависимости как в том же линухе.
проще сделать так .
то есть грузить библиотеки прямо с сайта разработчика, если есть возможность.
то есть грузить библиотеки прямо с сайта разработчика, если есть возможность.
А смысл? Не такие уж они большие эти библиотеки, что бы пользователь не мог их загрузить самостоятельно.
Да и идея реализуема только если будет полный архив всех версий библиотеки, и грузиться будет указанная разрабочиком.
Да и идея реализуема только если будет полный архив всех версий библиотеки, и грузиться будет указанная разрабочиком.
А что, если попробовать запихнуть все необходимые библиотеки в плагин, вызываемый на странице как-то так:
<object name="jsLib" data="export.js" type="application/x-javascript-lib" codebase="http://разработчик библиотеки.com/pub/jslib.cab#version=1,0,0,0\></object>
Через export.js будут просто импортироваться нужные функции. Возможно такой механизм и не получится реализовать, я не сталкивался с созданием сторонних плагинов. Но такая реализация решила бы проблемы с обновлением.
<object name="jsLib" data="export.js" type="application/x-javascript-lib" codebase="http://разработчик библиотеки.com/pub/jslib.cab#version=1,0,0,0\></object>
Через export.js будут просто импортироваться нужные функции. Возможно такой механизм и не получится реализовать, я не сталкивался с созданием сторонних плагинов. Но такая реализация решила бы проблемы с обновлением.
Вы не ту проблемы решаете. Я пытался исправить то что даже самая маленькая страница довольно долго подгружает библиотеки скрипта, большую часть из которых она вообще может не использовать.
Почему же не ту? Браузер видит объект (js-скрипт, импортирующий только необходимые функции и классы), который должен выполняться плагином. Если плагин ещё не установлен, то он загружается. В остальных случаях, вся необходимая библиотека уже находится на клиентской машине.
Ваша маленькая страница подгружает только функцию экспорта, состоящую из нескольких строк кода.
Ваша маленькая страница подгружает только функцию экспорта, состоящую из нескольких строк кода.
Буквально вчера появилась та-же идея :)
как вы предлагаете инструктировать браузер что нужно подключить определённую библиотеку?
обоснуйте свою идею: какие цели вы собираетесь преследовать, какова необходимость в нововведениях
обоснуйте свою идею: какие цели вы собираетесь преследовать, какова необходимость в нововведениях
Нужно всего лишь кросс-сайтовое кэширование библиотек:
[script vendor="http://vendor.com/lib.1.5.1.js" src="/lib.1.5.1.js"]
Доверять вендору будет уже не пользователь браузера, а создатель сайта, который хочет брать скрипт у вендора. Заодно размещает копию библиотеки у себя на случай, если вендор упал. Локальная копия не подсовывается другим сайтам (разумеется).
Старые браузеры будут юзать атрибут src как и раньше, новые браузеры могут смотреть на атрибут vendor.
[script vendor="http://vendor.com/lib.1.5.1.js" src="/lib.1.5.1.js"]
Доверять вендору будет уже не пользователь браузера, а создатель сайта, который хочет брать скрипт у вендора. Заодно размещает копию библиотеки у себя на случай, если вендор упал. Локальная копия не подсовывается другим сайтам (разумеется).
Старые браузеры будут юзать атрибут src как и раньше, новые браузеры могут смотреть на атрибут vendor.
Ой сколько чудес будет если часть скачается с сайта вендора, а часть - с локального сайта... Нужет файл в котором описано - что откуда брать и в каких случаях.
По моему полезнее (и проще) будет организовать где-нибудь надёжный Hosting для этих библиотек... Тогда ни расширений не нужно будет, ни проблем с версиями: всё всегда скачивается с сайта вендора - и никаких гвоздей. Добавьте туда manifest - и оно ещё и будет локально храниться в Google Gears "в рассчёте на будущее"...
По моему полезнее (и проще) будет организовать где-нибудь надёжный Hosting для этих библиотек... Тогда ни расширений не нужно будет, ни проблем с версиями: всё всегда скачивается с сайта вендора - и никаких гвоздей. Добавьте туда manifest - и оно ещё и будет локально храниться в Google Gears "в рассчёте на будущее"...
не бывает "надежного хостинга". Интернет - децентрализованный, в этом-то и прелесть. Живут же люди с десяткам зеркал для дебьян-пакетов и ничего, никто не умер еще.
pages.google.com - в эфире передача "попробуй завали"
Вы серьезно верите в "Большой Нерушимый Компьютер"? Как и в единственно верную линию партии, в возможность "собраться всем хорошим и убить всех плохих" и другие максимы? Если мне нужна библиотека, написанная Васей и выложенная на XYZforge.net, я ее оттуда и буду скачивать. Если нужна будет с QWERTYforge.net, буду скачивать оттуда. Или выберу одно из зеркал и буду качать с него. Или пропишу несколько зеркал. И никто мне не запретит создать свой репозиторий и приглашать людей им пользоваться. Потому что это интернет - здесь нет "главного сервера".
Если что, у Google нет "главного сервера". Это тысячи компьютеров в десятках data center-ов. И даже если какое-то количество компьютеров или даже центров выходит из строя, информация остается доступной. Вы когда-нибудь видели, чтобы google.ru не загружался при включенном интернете?
Насчет линии партии, совсем не понял. khim не предлагает собрать все библиотеки в одном месте, а все остальные запретить. Скорее, он говорит о том, что если предоставить удобный и надежный способ хостить библиотеки, будет хорошо. На один из примеров надежного и при этом бесплатного хостинга, я ссылку дал. Если кто-то напишет удобную морду к этому, внезапно может наступить счастье
Насчет линии партии, совсем не понял. khim не предлагает собрать все библиотеки в одном месте, а все остальные запретить. Скорее, он говорит о том, что если предоставить удобный и надежный способ хостить библиотеки, будет хорошо. На один из примеров надежного и при этом бесплатного хостинга, я ссылку дал. Если кто-то напишет удобную морду к этому, внезапно может наступить счастье
Неужто вы не понимаете? То, что у гугла 1001 сервер, мне по барабану. Если политика гугла вдруг круто изменится, то браузерная фича (кэширующая скрипты) перестанет работать как надо у кучи пользователей. А сайтостроители исправить это не смогут потому что кто-то решил завязаться на "Один Надежный Хостинг". Перечитайте мой самый первый комментарий. Там сказано, что каждый владелец сайта может указывать свой любимый репозиторий. Эффективность его будет пропорциональна количеству сайтов, которые используют тот же репозиторий и посещаются теми же пользователями. А какой это будет репозиторий и для каких скриптов, в данный момент времени — решает естественный отбор.
Теперь понял :)
Да, конечно, владельцу сайта никто не запрещает при изменении политики "Одного Надежного Хостинга" изменить манифест сайта с указанием "что-где брать" и таким образом пользователи даже не заметят, что источник сменился, разве что один раз сайт чуть медленнее загрузится.
Да, конечно, владельцу сайта никто не запрещает при изменении политики "Одного Надежного Хостинга" изменить манифест сайта с указанием "что-где брать" и таким образом пользователи даже не заметят, что источник сменился, разве что один раз сайт чуть медленнее загрузится.
Если накрывается "Один Надежный Хостинг", то проблемы возникают у ВЛАДЕЛЬЦЕВ САЙТОВ - и они их решают (а куда деваться), если ваш vendor вдруг начинает выдавать троярны(а случается это примерно с такой же частотой как и аварии с сайтами - нечасто, но да, случается-таки), то геморой возникает У ПОЛЬЗОВАТЕЛЕЙ. Честное слово: гениальности решения, которое способно МНОГОКРАТНО увеличить гемор в случае аварии и которое не дает НИКАКИХ преимушеств когда всё идёт "как надо" мне не понять. Вот такой вот я убогий, да...
Конечно можно исходить из того что владельцы сайтов - уважаемые люди, их жалко, а пользователи - это так... "быдло", тогда нововведение имеет смысл, но почему-то мне такой подход не очень нравится...
Конечно можно исходить из того что владельцы сайтов - уважаемые люди, их жалко, а пользователи - это так... "быдло", тогда нововведение имеет смысл, но почему-то мне такой подход не очень нравится...
Остановимся на том, что ваше предложение до конца четко не описано и вы, судя по всему, не понимаете, о чем идет речь. Перечисление красивых слов "google gears", "manifest", "Hosting", "никаких гвоздей" — это не предложение, а что-то типа политических высказываний.
Спросите krasin — она поняла.
// общение с анонимами-виртуалами нужно сворачивать...
Спросите krasin — она поняла.
// общение с анонимами-виртуалами нужно сворачивать...
>Спросите krasin — она поняла.
Изменение пола проведено намеренно? Вы не правы
Изменение пола проведено намеренно? Вы не правы
Моё предложение до конца не описано потому что все необходимые технологии уже есть, а вопрос о наилучшей структуре репозитария выходит далеееко за рамки технологий - это вопрос скорее политический, его нужно обсуждать отдельно.
Каким образом "браузерная фича" перестанет работать как надо при изменении политики Гугла - науке неведомо: Google Gears на то и лицензирован с использованем лицензии NetBSD чтобы от Гугла ничего не зависело и приниципы использования Google Gears похожи на то что Firefox предлалает: http://www.campd.org/stuff/Offline%20Cache.html , так что если даже КОНКРЕТНО Google Gears окажутся тупиковой веткой ЧТО-ТО ПОДОБНОЕ - точно будет...
Что же касается репозитариев - то в вашем случае они будут тоже нужны: если в половине случаев vendor'ный URL не будет работать - то зачем весь этот огород ? А если всё лежит в надёжном репозитории (с чего вы решили что это ОБЯЗАТЕЛЬНО должен быть Гугловый репозиторий?), то зачем нужна локальная копия и связанный с нею геморой (наличие двух "канонических" копий - это прямой путь к проблемам синхронизации).
Каким образом "браузерная фича" перестанет работать как надо при изменении политики Гугла - науке неведомо: Google Gears на то и лицензирован с использованем лицензии NetBSD чтобы от Гугла ничего не зависело и приниципы использования Google Gears похожи на то что Firefox предлалает: http://www.campd.org/stuff/Offline%20Cache.html , так что если даже КОНКРЕТНО Google Gears окажутся тупиковой веткой ЧТО-ТО ПОДОБНОЕ - точно будет...
Что же касается репозитариев - то в вашем случае они будут тоже нужны: если в половине случаев vendor'ный URL не будет работать - то зачем весь этот огород ? А если всё лежит в надёжном репозитории (с чего вы решили что это ОБЯЗАТЕЛЬНО должен быть Гугловый репозиторий?), то зачем нужна локальная копия и связанный с нею геморой (наличие двух "канонических" копий - это прямой путь к проблемам синхронизации).
Согласен с Вами, только чтоб vendor был бы как уникальное имя скрипта по типу URI.
И скрипт грузился не с сайта разработчика, а с src="/lib.1.5.1.js" в случае если в кеше нет такого скрипта.
И тогда отпадает проблема писать различные плагины.
И скрипт грузился не с сайта разработчика, а с src="/lib.1.5.1.js" в случае если в кеше нет такого скрипта.
И тогда отпадает проблема писать различные плагины.
Если скрипт будет грузиться с /lib, а кэшироваться как vendor.com/lib, и так выдаваться всем остальным сайтам — это называется "дыра в безопасности".
Атрибут vendor как раз указывает на конкретную версию софта и является уникальным URL. Локальная копия нужна, если вендор недоступен. Но она кэшируется только для одного сайта.
Атрибут vendor как раз указывает на конкретную версию софта и является уникальным URL. Локальная копия нужна, если вендор недоступен. Но она кэшируется только для одного сайта.
Чтоб не было дыры можно у вендора запросить хеш сумму данного файла и сверить с имеющейся хеш суммой закешированого файла.
Т.е. по существу, нужно хранить у вендора только контрольную сумму, а грузить с текущего сайта. Идея более чем здравая: не будет проблем с трафиком у вендора.
Получается вот что: контрольная сумма служит ключом в ассоциативном массиве "кэш браузера" и сайты, использующие одну контрольную сумму, используют общие кэшированные данные.
Тогда не нужно указывать сайт вендора — только контрольную сумму (ведь в vendor URI все равно неизменные данные). Если сравнение сумм не прошло, то файл кешируется не в глобальном кэше, а только для данного сайта. И все выглядит довольно шоколадно.
Получается вот что: контрольная сумма служит ключом в ассоциативном массиве "кэш браузера" и сайты, использующие одну контрольную сумму, используют общие кэшированные данные.
Тогда не нужно указывать сайт вендора — только контрольную сумму (ведь в vendor URI все равно неизменные данные). Если сравнение сумм не прошло, то файл кешируется не в глобальном кэше, а только для данного сайта. И все выглядит довольно шоколадно.
Сайт вендора как раз и нужно указывать, откуда тогда будем брать хеш сумму?
Идея замечательная можно использовать не только для js-скриптов.
Идея замечательная можно использовать не только для js-скриптов.
Контрольную сумму мы можем посчитать сами, а можем взять с сайта вендора. Только зачем браузеру ходить на сайт вендора? Там всегда одна и та же информация будет лежать (версия-то фиксированная). Если мы смухлюем в контрольной сумме, то просто прочитаем чей-то чужой публичный скрипт или, если такого не будет, получим скрипт с нашего сервера (но он не будет доступен другим сайтам).
Каждый раз ходить на сайт вендора не придется.
Только один раз при встрече незнакомого URL'а вендора.
Т.е. если в кеше нет вендора с таким-то URL'ом, то идем по указанному урлу и берем хеш сумму.
Получается так:
cache[hash_sum] = file
vendors[hash_sum] = [url, url, url, ...] (список урлов)
в идеальном случае:
vendors[hash_sum] = [url] (один урл)
Только один раз при встрече незнакомого URL'а вендора.
Т.е. если в кеше нет вендора с таким-то URL'ом, то идем по указанному урлу и берем хеш сумму.
Получается так:
cache[hash_sum] = file
vendors[hash_sum] = [url, url, url, ...] (список урлов)
в идеальном случае:
vendors[hash_sum] = [url] (один урл)
Не вижу разницы между содержимым сайта вендора и моим сайтом, если содержимое подписано. Непонятно, зачем хранить vendors[h] = [url, url, ...]. Мы же говорим о простом кэше. Нужно реализовать всего два действия: чтение и запись.
1) Чтение: берем контрольную сумму и используем как ключ (подсчет КС не производим, скачивание ни откуда не делаем). Если данных не нашлось, см. пункт 2.
2) Запись: скачиваем указанный в src файл, считаем КС, сравниваем с предоставленной КС. Если совпало — сохраняем в кэш с ключем - как раз этой КС ("глобальный кэш"). Если не совпало — кладем в кэш с ключем - собственным УРЛ "vasya.ru/lib.js" ("локальный кэш").
Вот и всё.
1) Чтение: берем контрольную сумму и используем как ключ (подсчет КС не производим, скачивание ни откуда не делаем). Если данных не нашлось, см. пункт 2.
2) Запись: скачиваем указанный в src файл, считаем КС, сравниваем с предоставленной КС. Если совпало — сохраняем в кэш с ключем - как раз этой КС ("глобальный кэш"). Если не совпало — кладем в кэш с ключем - собственным УРЛ "vasya.ru/lib.js" ("локальный кэш").
Вот и всё.
идея избавить пользователя от загрузки одних и тех же библиотек путём "интегрирования" их в брузеры переросла в раскидывание баблиотек по "любимым" репозиториям.
в FireFox есть свой репозиторий своих файлов. Например chrome://global/skin/netError.css. То есть ничего нового изобретать ненадо, достаточно только включить туда библиотеки. в IE тоже что-то подобное есть.
Но вот обновлять смысла думаю нет, разве только критические исправления и новые функции.
осталось только придумать стандарт для таких ссылок. (repository://lib/samplelib/samplecore.js) ну и хорошо попросить девелоперов ему следовать. И соответственную ссылку для мета тегов что данную библиотеку брузер может взять со своего репозитория, иначе качать там-то. а лучше и в брузеры вшить инфу где и какую библиотеку качать, а то умельцы быстро прочухают как эту дыру использовать.
А вобще лучше не использовать JS - и этот вопрос отпадает сам собой =)
в FireFox есть свой репозиторий своих файлов. Например chrome://global/skin/netError.css. То есть ничего нового изобретать ненадо, достаточно только включить туда библиотеки. в IE тоже что-то подобное есть.
Но вот обновлять смысла думаю нет, разве только критические исправления и новые функции.
осталось только придумать стандарт для таких ссылок. (repository://lib/samplelib/samplecore.js) ну и хорошо попросить девелоперов ему следовать. И соответственную ссылку для мета тегов что данную библиотеку брузер может взять со своего репозитория, иначе качать там-то. а лучше и в брузеры вшить инфу где и какую библиотеку качать, а то умельцы быстро прочухают как эту дыру использовать.
А вобще лучше не использовать JS - и этот вопрос отпадает сам собой =)
В идеале бы даже не javascript, а скомпилированную бинарную библиотеку подключать, чтобы быстрее рендерилось.
И пользователям давать выбор: либо обычный javascript исполнять, либо ставить плагин, чтобы все шустро работало.
И пользователям давать выбор: либо обычный javascript исполнять, либо ставить плагин, чтобы все шустро работало.
интересно, эта "бинарная библиотека" на каком языке будет написана что она шустрее обычного js будет?
На C/C++. Также, как обычный GUI быстрее JS UI, также и extension для браузера должен быть быстрее. Это все в идеале конечно.
А то, что предлагается - инклудить исходники js библиотек - это половинчатое решение.
А то, что предлагается - инклудить исходники js библиотек - это половинчатое решение.
позвольте, половинчатое в чём? вы уверены что цели вашего проекта совпадают с целями автора поста? похоже вы разное хотите усовершенстовать :-))
что касается С/С++, то актив-иксы уже делают это, разве что они не могут менять свой размер … ещё есть джава апплеты и jnlp — всё ж побыстрее джаваскрипта
что касается С/С++, то актив-иксы уже делают это, разве что они не могут менять свой размер … ещё есть джава апплеты и jnlp — всё ж побыстрее джаваскрипта
Цели автора не совсем понятны.
Сделать так, чтобы не нужно было загружать *.js файлы для каждого сайта? Ввести какую-то стандартизацию?
Но эти файлы gzipped сжимаются до 10-15 Kb - с трудом верится, что разработчики браузеров станут включать их в дистрибутив. Современные браузеры поддерживают gzip-распаковку.
Вот реальный недостаток клиентского js - скорость работы. Включить в браузер стандартную библиотеку + стандартные виджеты было бы здорово. Причем это должно быть не так как в активикс/апплетах. Должен быть стандартный API, реализация которого была бы и на Javascript тоже. То есть, если у клиента не установлен extension, то грузятся *.js файлы и приложение работает медленее, но все равно работает.
Это должно быть прозрачно - минимум головной боли веб-разработчику.
Сделать так, чтобы не нужно было загружать *.js файлы для каждого сайта? Ввести какую-то стандартизацию?
Но эти файлы gzipped сжимаются до 10-15 Kb - с трудом верится, что разработчики браузеров станут включать их в дистрибутив. Современные браузеры поддерживают gzip-распаковку.
Вот реальный недостаток клиентского js - скорость работы. Включить в браузер стандартную библиотеку + стандартные виджеты было бы здорово. Причем это должно быть не так как в активикс/апплетах. Должен быть стандартный API, реализация которого была бы и на Javascript тоже. То есть, если у клиента не установлен extension, то грузятся *.js файлы и приложение работает медленее, но все равно работает.
Это должно быть прозрачно - минимум головной боли веб-разработчику.
Ага. И на никсах она будет грузится в исходниках и компилироваться.
Flash называется.
Может "обезьянок" подождем? :)
Получаеться, дизайнер тоже должен думать, скачал ли клиент апдейт или ему не стоит вносить на сайт какой-то аплет? :/
Самое удачное решение проблемы повторного скачивания жабаскриптов это выделение их разработчиками сайта в ОТДЕЛЬНЫЙ ФАЙЛ и кеширование сего файла на прокси-серверах. Велосипед уже давно изобретен.
Например у меня стоит локальный кеширующий прокси-сервер handycache и, хоть он и имеет несколько неприятных особенностей (на понимает pipelining и типы файлов различает по названиям и пути к ним, а не по реальному типу или содержанию), но я им полностью доволен. Скрипт скачался — в следующий раз прийдет из кэша (с проверкой, а не обновился ли). Да, фокус не проходит с идиотскими решениями вроде картинок и скриптов "из бд по урлу", но меня устраивает.
Например у меня стоит локальный кеширующий прокси-сервер handycache и, хоть он и имеет несколько неприятных особенностей (на понимает pipelining и типы файлов различает по названиям и пути к ним, а не по реальному типу или содержанию), но я им полностью доволен. Скрипт скачался — в следующий раз прийдет из кэша (с проверкой, а не обновился ли). Да, фокус не проходит с идиотскими решениями вроде картинок и скриптов "из бд по урлу", но меня устраивает.
Очень похоже на runtime shared libraries у последнего флеш плеера - http://labs.adobe.com/wiki/index.php/Fle…
Там примерно таже идея - наиболее используемые либы отрывать и кэшировать. Зашел на один флекс-сайт - скачал все, зашел на другой - скачал только то что нужно, контролы и проч. подхватились от предыдущего посещения сайта. Флеш-плеер (суть браузер) кэширование контролирует.
Там примерно таже идея - наиболее используемые либы отрывать и кэшировать. Зашел на один флекс-сайт - скачал все, зашел на другой - скачал только то что нужно, контролы и проч. подхватились от предыдущего посещения сайта. Флеш-плеер (суть браузер) кэширование контролирует.
Коля разбушевался не на шутку...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Есть идея о библиотеках JS