rejetto forum
Software => HFS ~ HTTP File Server => Topic started by: Martok on February 26, 2006, 01:17:24 PM
-
Hello Rejetto,
As you said, PHP/CGI/whatever support would be quiet a hard thing to do. Maybe there is another possibility: using external programs/DLLs to generate the pages. For example, there could be a new file type 'dynamic', which would then be associated with a DLL/EXE that gets the parameters of the URL (that stuff after the ? like in posting.php?mode=newtopic) and other parameters(user defined). Then this app could write its generated HTML somewhere and HFS would deliver it to the client.
So if I add file '/forum/view.x' as 'dynamic' with EXE 'forum.exe', Parameter: 'view', and browse this file with
/forum/view.x?id=0815&SID=e4906245z062HFS would call
forum.exe "view" "id=0815&SID=e4906245z062" "C:\Temp\out456.tmp"then HFS would wait for the termination of this program, then send the file C:\Temp\out456.tmp to the client. The filename would be generated with WinAPI function GetTempFileName
I think this could be better than waiting for PHP and maybe even more flexible.
-
i fear it is not much easier than CGI
moreover, the main problem ATM is that i cannot get a stable enough release to continue working on major upgrades :?
-
Maybe I could help you and write a procedure to do the calling of the external app?
BTW: beta27 made no processQ for me :bounce:
EDIT: I made a function:
function GetDynPage(AppName, UserParams, URLParams:string; var Output:TStream):boolean;
var
SUInfo: TStartupInfo;
ProcInfo: TProcessInformation;
CmdLine,TempFile: string;
Path:array[0..Max_Path] of char;
s: array[0..Max_Path] of char;
begin
// Generate Temp File
GetTempPath(Max_Path,Path);
GetTempFileName(Path, 'hfs', 0, s);
TempFile:= s;
DeleteFile(TempFile);
{ Enclose filename in quotes to take care of
long filenames with spaces. }
CmdLine := format('"%S" "%S" "%S" "%S"',[AppName,UserParams ,URLParams,TempFile]);
FillChar(SUInfo, SizeOf(SUInfo), #0);
with SUInfo do begin
cb := SizeOf(SUInfo);
end;
Result := CreateProcess(NIL, PChar(CmdLine), NIL, NIL, FALSE,
CREATE_NEW_CONSOLE or
NORMAL_PRIORITY_CLASS, NIL,
PChar(ExtractFilePath(AppName)),
SUInfo, ProcInfo);
{ Wait for it to finish. }
if Result then
WaitForSingleObject(ProcInfo.hProcess, INFINITE);
// Load Temp File if Present
if FileExists(TempFile) then
Output:= TFileStream.Create(TempFile,fmOpenRead)
else
Output:= nil;
end;
// Sample Call:
// The caller has to ensure that the output stream is not assigned
procedure TForm1.Button1Click(Sender: TObject);
var str:TStream;
app,user,url,p:string;
begin
app:= 'C:\Serv\tools\doit.exe';
user:= 'test';
url:= 'http://localhost/test/dynamic.x?a=12&b=5';
p:= copy(url,pos('?',url)+1,maxint);
if GetDynPage(app,user,p,str) then
ShowMessage('Done. We could send stream str here');
end;
I noticed you already have a possibility to send a stream with the bodyStream property of the reply object. Maybe this could be used?
-
what if the external application or CGI hangs or takes long?
i fear this will need a multithreaded server
that means, a lot of work
-
what if the external application or CGI hangs or takes long?
i fear this will need a multithreaded server
Yes, you are right. I just have not thought about lengthy operations yet. I just thought about some seconds.
And for the hanging issue, maybe there could be a timeout?
Sure, making HFS multithreaded would be a large change, but wouldn't it be possible to make only the processQ a different thread? So the queue itself and the sending stuff is still in the main thread? And for a server with many users, I think multithreading would be better even without new features. So better add it now than later, before it would become an even larger change.
-
Yes, you are right. I just have not thought about lengthy operations yet. I just thought about some seconds.
And for the hanging issue, maybe there could be a timeout?
in those seconds the server would not be able to answer anything else.
Sure, making HFS multithreaded would be a large change, but wouldn't it be possible to make only the processQ a different thread? So the queue itself and the sending stuff is still in the main thread?
and have page generation in a single thread? i see no gain
And for a server with many users, I think multithreading would be better even without new features.
why? i don't see any real delay in the way HFS serves requests.
-
and have page generation in a single thread? i see no gain
I thought maybe this is easier to implement. But a different approach: When there is a request, a new thread is created and generates the reply, then tells the main class to send it and frees itself.
why? i don't see any real delay in the way HFS serves requests.
I also don't, but it would be easier to extend it later.
-
and have page generation in a single thread? i see no gain
I thought maybe this is easier to implement. But a different approach: When there is a request, a new thread is created and generates the reply, then tells the main class to send it and frees itself.
this makes sense
why? i don't see any real delay in the way HFS serves requests.
I also don't, but it would be easier to extend it later.
i won't add bugs today to have features tomorrow ;)
-
this makes sense
nice to hear ;)
i won't add bugs today to have features tomorrow ;)
As I said before, beta37 seems to have no bugs for me! And according to the non-existing posts in the ProcessQ-Thread, others also don't have!
Anyway, I agree: adding this to an unstable version could make it even unstabler.
-
it's sad but i had a processQ in beta37.
anyway, if it is highly reduced, i could also publish 2.0 as stable.
-
ProcessQ is very mysterious. It is reducable, but not killable.
In older versions, i noticed another thing: most of my ProcessQs occured when i was browsing form a different machine, local browsing produced errors only very little.
You said you knew how to reproduce it, has the client something to do with it or is it just a 'statistical anomaly'?
I thin it is stable enough, and people using the current 'stable' 1.6a miss a lot. I myself used 1.6a for a long time, but started 2.0 at beta21. The difference was quiete shocking!
Ooops, this is getting off-topic :#) , I better stop here.
-
You said you knew how to reproduce it, has the client something to do with it or is it just a 'statistical anomaly'?
this bug is not related to a specific client
I thin it is stable enough, and people using the current 'stable' 1.6a miss a lot. I myself used 1.6a for a long time, but started 2.0 at beta21. The difference was quiete shocking!
let's see how it goes