Поддержка PHP скриптов

[Parasite]

различные костыли вроде проксей с теми же неповоротливыми скриптами

В чем заключается "неповоротливость скрипта" в данной конкретной теме? Вменяемо написанный скрипт вполне успешно держит 100-200 одномоментных параллельных подключений без каких-либо проблем (и это обычная нагрузка на обычном стареньком ноутбуке - а не максимальная на серверном железе, на нём мне так и не удалось нагрузить сабж на 100%). Это на порядок больше, чем обычно открывают окошек закачек в САСе.

PS: обсуждаемая тема "как обмениваться межтредовой информацией" легко и не нарушая сна решается тем же постоянно висящим в памяти проксиком. Очередной костыль? Да. Но что же касается гипотетических плагинов....+1 к предыдущему оратору.

PPS: а еще легче - [до момента вменяемой поддержки со стороны разработчиков] не связываться с САСовой качалкой вообще ввиду очевидных недостатков, а вытянуть все что нужно в его кэш своими силами. САС при этом будет только просмотрщиком уже готового кэша. Рюшечки и погремушки в нем - это конечно хорошо когда всё основное хорошо работает, ан нет - весьма серьезные грабли в багтрекере назначены на весьма далекое будущее.

[nafa]

А в чем проблема то с PHP ? Им и сейчас можно пользоваться. На любом веб-сервере размещаете скрипт, прописываете его в zmp и делайте с ним что хотите.

[Parasite]

А в чем проблема то с PHP ? Им и сейчас можно пользоваться. На любом веб-сервере размещаете скрипт, прописываете его в zmp и делайте с ним что хотите.

Это и называется "прокси-скриптик". И що б мы без Вас делали, а....
А проблема с ним в том, что это очередной костыль к САСу - а не часть его собственного функционала. И тут народ и пытается хоть как-то поправить сий расклад. Lua и Perl предлагались ровно для того же с год назад, сейчас очередь PHP. Скорее всего - с тем же результатом.

[nafa]

А проблема с ним в том, что это очередной костыль к САСу - а не часть его собственного функционала.

А что плохого в том, что это не часть его функционала? Для работы с файловой системой мы же пользуемся готовыми функциями а не пишем свои и т.п.
Про затраты времени на вызов скриптов - они конечно есть, но все-таки основное время занимает получение информации с сервера (особенно с включенным антибаном), так что не думаю, что они играют какую-то роль. Для тех, кому важна лицензионность - Apache бесплатен, PHP бесплатен. Так что не понимаю зачем разработчикам тратить силы на то, что пользователи вполне могут сделать самостоятельно. У них и без этого проблем хватает (см. багтрекер).
И никакой этот прокси-скрипт не костыль. Позволяет делать много полезного. Например, полученный тайлы можно складывать в базу данных, благодаря чему обеспечить хранение истории карт (т.е. чтобы можно было просматривать информацию на определенную дату, что очень ценно для спутниковых снимков, т.к. они обновляются).

[Parasite]

А проблема с ним в том, что это очередной костыль к САСу - а не часть его собственного функционала.

А что плохого в том, что это не часть его функционала? Для работы с файловой системой мы же пользуемся готовыми функциями а не пишем свои и т.п.

Плохого в этом то, что мы тут развиваем конкретную программу и ее универсальность - а не пишем каждый свои инструменты кто в лес, кто по дрова. А то по этой дорожке можно далеко уехать - вплоть до вопроса "А что плохого вообще не пользовать САС - ведь для работы с картами есть гораздо более мощные ГИСы и прочие Фотошопы?".
Вам действительно нужен ответ на этот вопрос?

Так что не понимаю зачем разработчикам тратить силы на то, что пользователи вполне могут сделать самостоятельно. У них и без этого проблем хватает (см. багтрекер).

От разработчиков требуется самая малость - всего лишь дать возможность влиять внешним инструментам на внутренние процессы и калькуляции САСа (в данном случае - на хидеры сокета). Всё! Никто тут от них не требует переписать САС полностью на PHP....хотя идея конечно хорошая.....

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

Вы повторяете мои слова двухлетней давности в теме "Чего вы хотите" - практически слово в слово.

[zed]

Так что не понимаю зачем разработчикам тратить силы на то, что пользователи вполне могут сделать самостоятельно. У них и без этого проблем хватает (см. багтрекер).

Вопрос даже не так стоит: разработчикам не надо тратить силы, а нужно лишь дать "добро" на то, чтобы пользователь (в моём лице) попробовал это сделать по оговоренной выше логике. От текущих проблем я отвлекать разработчиков не намерен.

[nafa]

разработчикам не надо тратить силы, а нужно лишь дать "добро" на то, чтобы пользователь (в моём лице) попробовал это сделать по оговоренной выше логике

Чем реально прокси-скрипт не устраивает?

А что плохого в том, что это не часть его функционала? Для работы с файловой системой мы же пользуемся готовыми функциями а не пишем свои и т.п.

Плохого в этом то, что мы тут развиваем конкретную программу и ее универсальность

Из пользователей апача 90% используют также и PHP, и удивительно - всех - и разработчиков и пользователей устраивает что это 2 разные программы. А PHP в SAS будут использовать дай бог 5%, они уже имеют возможность это делать, но непременно подавай встроенную поддержку.

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

Вы повторяете мои слова двухлетней давности в теме "Чего вы хотите" - практически слово в слово

И что мешало за два года это самому реализовать хотя бы той же проксей?

[zed]

А PHP в SAS будут использовать дай бог 5%, они уже имеют возможность это делать, но непременно подавай встроенную поддержку.

Почему вы так уверены? Тут же ж как раз и разговор о том, что прокси-скрипт реально используют единицы, но можно устроить так, что будут его (php) использовать все/большинство даже не подозревая о том, что они это используют.
Плюс ко всему, PHP и SAS как были независимыми программами, так ими и останутся, единственное, что SAS, так же как и Апач сумеет запускать на исполнение пхпэшные скрипты.

Из пользователей апача 90% используют также и PHP, и удивительно - всех - и разработчиков и пользователей устраивает что это 2 разные программы.

Однако, Апач умеет работать с PHP, а SAS пока что не умеет.

[Parasite]

Вы повторяете мои слова двухлетней давности в теме "Чего вы хотите" - практически слово в слово

И что мешало за два года это самому реализовать хотя бы той же проксей?

Мешает наличие понимания того, что то что я желаю иметь ОТ САСа - это вовсе не то, что я желаю иметь ВООБЩЕ. Намного больше я ему желаю хорошего как программе (чисто академически), чем желаю потому что мне это внезапно стало нужно.
Когда мне внезапно станет что-то нужно - я это сделаю сам намного быстрее, чем дождусь от САСа. Со скриптами я работал еще в прошлом веке, да и сейчас с ними работаю на порядки больше чем с САСом - имея прямо сегодня то, что САСу светит году так в 2015м по роадмапу его же разработчиков (и хидеры, и POSTы, и нестандартные размеры тайлов вкупе с датабазами, и сведение безразмерных изображений в RAW и всяким таким прочим - всё это, разумеется, есть, и весьма плотно юзается). Чего и Вам желаю.

Апач умеет работать с PHP, а SAS пока что не умеет.

А зачем тут Апач? На скриптах прекрасно пишутся standalone-проксики, которые вполне самостоятельны в пределах шелла. При этом разницы с "из-под апачевскими" - ну буквально пара строк кода.
Вот шаблон перлового однопоточного проксика:

Код: Выделить всё

#!/usr/bin/perl
use HTTP::Daemon;
my $server = HTTP::Daemon->new( LocalPort => $port ) or die "Can't start server ($@)" unless defined $server;
while (my $conn = $server->accept) {

        <.......тут обработка если пойман коннект......>

}

А вот - шаблон с форками (мультипоточный):

Код: Выделить всё

#!/usr/bin/perl
use strict;
use base qw{ Net::Server::Fork };
my $serv = LWP::UserAgent->new(
        agent   => 'Mozilla/4.0',
        keep_alive  => 1,
        max_redirect => 0,
    );
connected();
__PACKAGE__->run( port => $port );

connected {
        <.......тут обработка если пойман коннект......>
}


Апач [в данном конкретном вопросе] - не нужен, ибо это забивание гвоздей микроскопом. KISS-KISS, bang-bang...

[vasketsov]

перлового однопоточного проксика

Всё так и есть, я запускаю перл из простого батника, и апач мне не нужен )))))))