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

[vasketsov]

надо как-то звать того же перла с САСа, отдавать ему данные, а в ответ как-то получать выхлоп обратно в САС

Ну тут принципиально два варианта, с небольщими вариациями.

Первый - это когда по набору параметров (условно, доступных качалке) запускается вместо паскальскрипта нужный перлскрипт.
На первый взгляд ничего принципиально не меняется. Но это только на первый )).
Самое главное отличие - что как уже было справедливо отмечено, будет доступен весь функционал доступный языку в системе (со всеми установленными в перла дополнительными CPAN-модулями и тд.).
Самая главная беда (исключая пока что главнейшую проблему - как оно вообще будет совокупляться через какую либу) - это сборщик мусора и поддержка соединений.
В общем всё примерно как для PHP с keep-alive и прочими блекджеками.

Второй - условно режим прокси-сервера. Весьма схож с тем, что сейчас крутится (то есть прямо натуральный http-сервер, как сейчас подымается). Только отличие в том, что возможно получится некоторые параметры скрипта инициализировать прямо из саса (например подсунуть ему номер порта, версию, путь до кэша, отдать какие-нить настройки и т.п.), равно как что-нибудь от него забрать (ещё при инициализации, например Key для bing-а или ещё чего). Соответственно сам http-сервер обладает всей полнотой способностей (как и сейчас), а скрипт скачки в сасе пишется крайне тупой и простой, хоть опять же на том же паскальскрипте, хоть на перлскрипте (в этом контексте второй - продолжение первого), поскольку вся логика перенесена на http-сервер (опять же как сейчас имеет место).
По сути в первом приближении ничем не отличается от того, что сейчас, если бы сейчас http-сервер поднимался бы автоматически при запуске саса (что опять же решается батником).

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

Но поскольку я ещё даже не придумал метод совокупления - срочные ответы не требуются )))

[vasketsov]

Вощем метод совокупления придумался. До жути универсальный.

Прога:

скрытый текст: показать

program PerlInDelphi;

{$APPTYPE CONSOLE}

uses
ActiveX, ComObj,
MSScriptControl_TLB, // можно даже без этого, тупо через IDispatch
Variants,
Classes,
SysUtils;

var
sc: IScriptControl;
sl: TStringList;
varr,res: Variant;
pPar: PSafeArray;
begin
CoInitialize(nil);
try
// get IScriptControl
sc := CreateOleObject('MSScriptControl.ScriptControl') as IScriptControl;
sl := TStringList.Create;
try
// common part (initialization)
sc.Language := 'PerlScript';
sl.LoadFromFile('test.pl');
sc.AddCode(sl.Text);

// single call (for every item)
varr:=VarArrayCreate([0, 1], varVariant);
varr[0]:='1';
varr[1]:='5';
pPar:=PSafeArray(TVarData(varr).VArray);
res:=sc.Run('func2',pPar);
Writeln(res);
finally
sc := nil;
sl.Free;
end;
except
on E:Exception do
Writeln(E.Classname, ': ', E.Message);
end;
end.

Скрипт для теста:

скрытый текст: показать

#!/usr/bin/perl

use strict;

sub func2 {
my ($a,$b)=@_;
print "func2 $a and $b\n";
return "func2 return $a and $b\n";
}

print "ooops\n";
return "nothing\n";

Выводит в консоль
ooops
func2 1 and 5
func2 return 1 and 5
Первое - от print из perl, второе - результат совокупления return (из функции!) и Writeln(res).
Нужные параметры передаются понятно как.
Основное тело скрипта отрабатывает до запуска функции.
Вощем красота.

Короче, всё предельно просто и универсально. Вместо PerlScript можно юзать жаваскрипты, вбскрипты, пхпскрипты и т.п. абсолютно без пересборки EXE, только надо на нужном языке скрипт писать. Так что остался первый вопрос - по скорости работы. И второй вопрос - как бы так извратиться, чтобы передавать только нужные параметры (как вариант - звать доп. функцию, которая собственно и вернёт, чёго надо будет в работе).

[vdemidov]

В этом методе будет проблема с пробрасыванием объектов из САСа в скрипт. Все объекты нужные скрипту придется делать наследниками IDispatch со всеми вытекающими последствиями. Хотя в общем метод неплохой.

[Parasite]

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

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

Опять же хочу обратить твое внимание на прогу HandyCache - в которой как раз весьма грамотно и реализована концепция "с внешнего скрипта можно рулить практически всеми параметрами программы, причем там можно наворотить весьма много чего сколь угодно сложного". Документация и примеры скриптов - доступны на handycache.ru.

[vasketsov]

В этом методе будет проблема с пробрасыванием объектов из САСа в скрипт

Да собственно там Downloader - на который совсем не жалко и забить.
А также Proj4 - вот с ним грустно, хотя даже не глядя на cpan.org, почти уверен, что внутри скрипта тоже всё можно сделать.
То есть цимус-то как раз - не тащить туда объекты.
То бишь остается формально 2 задачи:
а) передать все нужные (а не вообще все) параметры в скрипт;
б) сделать хранение произвольных скриптовых параметров между запусками (если конечно не запускать сервер в основном теле скрипта, тогда эта задача вообще не нужна).
Ибо задача получения ответа от скрипта как оказалось самая простая ))).

Все объекты нужные скрипту придется делать наследниками IDispatch со всеми вытекающими последствиями

Вот уж чего-чего, а этого как раз хочется избежать )))

В идеале было бы прекрасно если бы можно было перекрывать все САСовые константы\переменные имеющие отношение ко взаимодействию "наружу"

Я конечно понимаю, что скрипт в принципе даже себя может править ))) но зачем переуправление прараметрами из zmp например?

Вот например таймаут на сетевые операции при работе с конкретной картой

А это можно сделать на перле? А то не очень понимаю, какая информация конкретно от саса нужна будет perl-у для этого.

возможность подложить конкретный сертификат для конкретного https

Это можно сделать на перле, если им и качать. Сас об этом даже знать не будет.

Кстати это касается не только запросов на\из качалки - кэш-то у нас тоже "наружу"

Дык собственно самый главный вопрос "чего надо ещё передать скрипту" как раз и касается параметров, НЕ СВЯЗАННЫХ с качалкой.
Просто потому что любой параметр, связанный с качалкой, легко достаётся в скрипт при необходимости.
А все более далёкие параметры (типа текста параметров из zmp) и могут вызывать потенцальные проблемы.

иногда надо "положить вот этот тайл не туда где он должен лежать в кэше указанного для карты типа, а в совершенно постороннее указанное Васей место, и даже вообще на другом томе\компьютере".

Или в БД (это не касается "стандартного" кэша в СУБД). Но ни один параметр складывания тайлов в БД (там где они скриптом у меня кладутся) не берётся из саса. Сас даже не знает об этом.
А вопрос необходимости передачи прежде всего касается тех параметров, о которых знает сас. Например вот мне надо было параметры загрузки - переписываются ли тайлы в кэше (чтобы в БД также синхронно их или переписывать или нет). Сейчас они не передаются. Между тем возможно быстрее будет сразу класть тайл в кэш из скрипта, и отвечать качалке "сделано! лежит там".

HandyCache

Ага, смотрю уже.

[vdemidov]

Да собственно там Downloader - на который совсем не жалко и забить.

А потом рассказывать пользователям почему у них карта не работает, хотя в настройках программы настройки прокси прописаны правильно и все остальные карты качаются нормально?

[vasketsov]

Хм. А что поменяется (в плане рассказов юзерам), если Downloader таки вдруг пропихнётся в виде IDispatch в скрипт? )) Равно как с ним, так и без него, скрипт вполне может не работать, причём без видимых причин с точки зрения юзера, не знающего, на чём написан скрипт и что он делает.