проверять файлы при каждом генерации страницы — это также глупо, как и оптимизировать сам процесс.
fopen или get_headers — для данной операции не имеет значения :)
Только это все приложения «hello word». А в случае таких приложений мы можем сравнивать только уровень накладных расходов на старт приложения. Поскольку функционал больше ни для чего другого не используется.
Таких API, наверное, уже десятки, просто нужно чтобы использовалось что-то одно :)
Занимаясь разработкой задач чуть более сложных чем просто 3-5 страниц вебсайта понимаешь — всеравно придется допиливать напильником :) поэтому KISS важнее REST (для меня).
Для меня гораздо более интересно мета-програмиирование с самогенерирующимся и самомодифицирующимся кодом.
Вы видели неленивого программиста? :) Так что очень даже аргумент.
А если вернутся к динамическим страницам…
Представьте себе биржевые котировки и их историю включая различные условия и фильтры. Фактически для хранения подобной информации потребуется места на порядки больше чем имеется самой информации. Страница с такими фильтрами, страница с другими фильтрами…
Нужно ли такое кеширование? :)
Более того оно реализовано в текущих браузерах в виде истории посещенных страниц. Подходит ли это для веб-приложений?
Пока далеко не все браузеры это поддерживают, да и те, что поддерживают, дают не такие уж большие объемы. А нынешние cookie слишком малы для этого :) вот хранить хеш — самое то.
Во флеше хранилище есть.
Но в любом случае имея закешированные данные (исключая справочики и прочую статику) получите геморрой с репликацией на 10-1000 клиентов. Оно вам надо?
Что касается любой попытки уйти от HTTP, то этим вы просто часть функций веб-приложения перекладываете на дополнительное ПО сервера и клиента. (ту же авторизацию)
Все удобство веб-приложений, как раз и заключается в том, что клиент получает части приложения дистанционно и может работать с ними, при этом ему не надо заботиться об актуальности приложения. Используя единую среду (браузер) он может выполнять сколь угодно много приложений.
Да, мы можем написать свою программу-клиент, но она будет заведомо тяжелее для разовой загрузки и будет иметь больше проблем с обновлением и более того для каждого приложения потребуется свой клиент :)
А это как раз то, от чего хотели уйти используя веб, а не просто сеть. Внутри же большинства не-веб приложений REST успешно заменяется CRUD. Поскольку имея отдельный клиент нам нет необходимости беспокоиться о едином API для множества приложений.
Точнее сложности с новым классом имеются далеко не во всех языках.
Никто не мешает мне точно так же как URI добавить новый метод обнаруженный в WSDL. Причем класс это сделает автоматически обнаружив, что он(метод) вызывается в моем коде.
Команды консоли ей учить стоило в то же время?
«даже DVD» — это, видимо, огромная заслуга для плейера в 2009м году :(
Вы полагаете, что все вышеперечисленное должен знать «каждый обычный пользователь»?
fopen или get_headers — для данной операции не имеет значения :)
Какие есть возможности для проверки наличия файла на другом сервере?
Занимаясь разработкой задач чуть более сложных чем просто 3-5 страниц вебсайта понимаешь — всеравно придется допиливать напильником :) поэтому KISS важнее REST (для меня).
Для меня гораздо более интересно мета-програмиирование с самогенерирующимся и самомодифицирующимся кодом.
Вы видели неленивого программиста? :) Так что очень даже аргумент.
А если вернутся к динамическим страницам…
Представьте себе биржевые котировки и их историю включая различные условия и фильтры. Фактически для хранения подобной информации потребуется места на порядки больше чем имеется самой информации. Страница с такими фильтрами, страница с другими фильтрами…
Нужно ли такое кеширование? :)
Более того оно реализовано в текущих браузерах в виде истории посещенных страниц. Подходит ли это для веб-приложений?
Во флеше хранилище есть.
Но в любом случае имея закешированные данные (исключая справочики и прочую статику) получите геморрой с репликацией на 10-1000 клиентов. Оно вам надо?
Что касается любой попытки уйти от HTTP, то этим вы просто часть функций веб-приложения перекладываете на дополнительное ПО сервера и клиента. (ту же авторизацию)
Все удобство веб-приложений, как раз и заключается в том, что клиент получает части приложения дистанционно и может работать с ними, при этом ему не надо заботиться об актуальности приложения. Используя единую среду (браузер) он может выполнять сколь угодно много приложений.
Да, мы можем написать свою программу-клиент, но она будет заведомо тяжелее для разовой загрузки и будет иметь больше проблем с обновлением и более того для каждого приложения потребуется свой клиент :)
А это как раз то, от чего хотели уйти используя веб, а не просто сеть. Внутри же большинства не-веб приложений REST успешно заменяется CRUD. Поскольку имея отдельный клиент нам нет необходимости беспокоиться о едином API для множества приложений.
Точнее сложности с новым классом имеются далеко не во всех языках.
Никто не мешает мне точно так же как URI добавить новый метод обнаруженный в WSDL. Причем класс это сделает автоматически обнаружив, что он(метод) вызывается в моем коде.
все остальное будет вольной интерпретацией текущих сессий.