From: Hector Santos on
Peter Olcott wrote:

>> Is this an ACTIVEX, FLASH or JAVA client side file upload
>> component?
>
> It is an HTML web page, BrowseFile widget.


What BrowseFile Widget? When you say "widget" to me, you are talking
about something extra that is installed.

>> Whats wrong with just using standard HTML INPUT
>> type="file" control with a HTTP upload to a basic HTTP
>> server?
>
> That is what I am using.


See what I mean. That is not a "Widget" that is that the standard
HTTP file upload idea. The browser has their own way for displaying
a browser file selection window. I guess that might be called a
"widget" in the technical sense.

>> Now, when you using any advanced method other than HTTP,
>> you can define your own communication I/O with a
>> persistent connection.
>>
>> In this case, it isn't FASTCGI - but a simple backend
>> server. Call it want you want, it is still a backend
>> server.

> Maybe this is simpler, but it the HTML Button is already
> sending the data in CGI format, wouldn't FastCGI be simpler?


If you using the HTML File Upload Tag, that is not a "CGI format."

Ok, this is what I mean. Look the flow is like this:

BROWSER --> HTTP REQUEST ---> WEB
BROWSER <-- HTTP RESPONSE <--- WEB


To get AWAY from this, you need "Special Pluggins" that will connect
on a different post and do communications. The HTTP File Upload is
not one of these extra pluggins, it will use the standard HTTP
protocol. It is only a "widget" in the sense that each browser will
run a local Native GUI as the file selection browser. Most browsers
will simply run an client side pluggin to run the WIN32 OpenDialog
Functions.

So, when you click SUBMIT, there is no CGI format here. It is here:

WEB ---> "APPLET"

The WEB will start a "Processor Applet" for the HTTP REQUEST.

The APPLET can be:

- Embedded (built into the server). Ours embedded,
IIS/ASP is embeded

- Non-Embedded, External Process - called SCRIPT MAPPING.

There are two kinds of SCRIPT MAPPING:

- EXE PROCESS, this generally has a /CGI/ or /CGI-BIN/ alias

example:

/yourdomain/cgi-bin/myOCR.EXE

The web server as a backend configuration for the actual
location of /cgi-bin/ alias.

- EXTENSION BASED SCRIPT EXE PROCESSOR

example:

/yourdomain/myprojects/myOCR.PHP

In BOTH cases, there are processed as a CGI process using CGI
standards, such as the one identified in the IETF RFC 3875

http://www.ietf.org/rfc/rfc3875

the different is that as a SCRIPT map, the MyOCR.PHP is the name of
the script passed to the PHP-CGI.EXE process spawned by the web
server. As a pure CGI, there is no script to pass.

So the web server can spawn:

Pure CGI:

c:\protected-cgi-bin\myocr.exe

Script Map Extension:

c:\php525\php-cgi.exe c:\web-root\myprojects\myocr.php

In both cases:

WEB --> ENVIRONMENT TABLE --> CGI process
Standard input (posted data)

WEB <-- Standard output (HTML?) <-- CGI process

So when you say "FASTCGI" you (THE WEB SERVICE) are basically setting
up a 24x7 service pool that will take this information as it was a CGI.

So when you speak of FASTCGI, you are either:

1) Creating a actual FASTCGI server that will do all the pooling,
thread management, listening servers, spawning of threads,
pretty much starting with the CSPServer codeproject code I
sawed.

2) Creating a script, like in PHP that will run on a FASTCGI
supported server with PHP-CGI.EXE. The server has to support
this.

The reason for #2 is because you want to create this as single thread
and the SCRIPT CGI processor will run it for you as a single thread.

What I am telling you is that you need to concentrate on the actual
program that will:

Read the CGI information (Environment Strings)
Standard Input (posted data)

regardless if its handled as a FASTCGI or not. It has nothing to do
with FASTCGI per se.

Now, if you had a special WIDGET that doesn't use HTTP, or could use
HTTP, but it directly connected to the backend server, you really
don't have a FASTCGI concept, but a client/server concept.

If that is what you want, then you got your work cut out for you.


--
HLS
From: Hector Santos on
Peter Olcott wrote:

> Not in the case of FastCGI, FastCGI does not use environment
> variables.


Thats not true. PHP-CGI.EXE -b FASTCGI mode read env strings.

--
HLS
From: Hector Santos on
Peter Olcott wrote:

>> So again, what web server?
>
> I will probably be using some version of Apache because I
> will probably be hosting this under one flavor of Linux or
> another.
> (1) My App must remain alive it can not terminate, it must
> keep at least most of its data in memory, even if I have to
> write another process to force this.


Over Design is a symptom of knowing how things work. :)

> (2) I will probably be using the HTML BrowseForFile button
> as the user interface, thus the PNG file will be coming as
> URL-encoded CGI format.


No, it will not be coming in "CGI Format" (whatever that is), not if
you are using a standard HTML <input type="file" /> tag.

"CGI Format" could only possible mean two types on input:

Environment Strings
Standard Input.

and one form of output

Standard Output

see the RFC 3875 and the OReilly CGI Programming guide on the web:

http://oreilly.com/openbook/cgi/

FASTCGI doesn't change any of the above.

--
HLS
From: Hector Santos on
Peter Olcott wrote:

>> In this case, it isn't FASTCGI - but a simple backend
>> server. Call it want you want, it is still a backend
>> server.

> Maybe this is simpler, but it the HTML Button is already
> sending the data in CGI format, wouldn't FastCGI be simpler?

Peter to summarize this:

1) HTML/HTTP does not send "CGI Formats."

2) You would not be writing a FASTCGI server. You would be running
a writing a process that would run as a CGI under a FASTCGI
pool managed by the web server.

3) If you going to use Apache, you will be writing a PHP script as it
only supports FASTCGI for PHP.

Based on your comments, what you really want is very simple:

Your own special WEB SERVER with the built-in code for your work.


--
HLS
From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:OJiTrWYxKHA.6140(a)TK2MSFTNGP05.phx.gbl...
> Peter Olcott wrote:
>
>
>> It seems to me that most of you guys continue to simply
>> ignore some of my most fundamental design requirements.
>> App load time for me can be several minutes, app
>> execution time of a large job is never more than 100
>> milliseconds.
>
>
> Thats because you didn't know about NT old technology
> called Memory Mapped Files.
>
>> The web service needs no GUI. It is all PNG in, and UTF-8
>> out.
>
>
> A web service is just a HTTP protocol processor. What it
> does is based on the URI or specifically script-path:
>
> <scheme> "://" <server-name> ":" <server-port>
> <script-path> <extra-path> "?" <query-string>
>
> But the I/O is the same across the board.
>
>> All that I know for sure is that some of my fundamental
>> requirements are immutable. Some of Hector's advice
>> seemed to continue to ignore these requirements.
>
>
> Until you mentioned the 4GB I realized your layman
> thinking why you believe FastCGI is your answer - it
> isn't. You need to use Memory Mapped Files and until you
> realized this everything else is a moot point.
>
>> I was envisioning the web service as a single
>> application. This
>
> > may not have been the way that he was envisioning it.
>
> Of course I was because I know YOU were not be too
> sophisticated but to do it any other way and this is why I
> said your reasons for FASTCGI were not incorrect.
>
> When you say "FASTCGI", you are talking about a "service"
> that the web server connects too. Not the client. I know
> you won't be able to do it because short of using PHP, you
> need to write a C/C++ client/server that does everything a
> CGI application will do - standard I/O.
>
> Again I ask, what web server will be using?
>
> If you are will be writing your own WEB SERVER (HTTP
> processor), you will be created a embedded solution - you
> won't need FastCGI.

I read some technical docs on FastCGI, and it reminded me
that the client calls may have many packets that are coming
from different sources and these packets may not be in the
right order. Part of what FastCGI does is directly handling
the multiplexing of this. Does your solution include this
multiplexing?

>
> Now, as I mentioned, the old reason was slower machines
> and process startups. That isn't the case today. Today,
> FASTCGI is not as important and also most systems are
> going to the alternative - embedded solutions.
>
> So again, what web server?
>
> PS: Please quote the mail better, no need to quote the
> entire message for one or two lines.
>
> --
> HLS