From: Peter Olcott on

"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message
news:ea%23kdFVxKHA.5576(a)TK2MSFTNGP05.phx.gbl...
> Peter Olcott wrote:
>
>>
>> I would be doing FastCGI in C++, if I do it. I am
>> considering FastCGI because I need a completely portable
>> way for a user to browse for a PNG file to send to my
>> server. HTML has this built in, and it is connected to
>> CGI. As far as a protocol goes, this would be trivial.
>> The user sends a 24-bit PNG file, the server sends back
>> UTF-8. That's the whole protocol. Sometimes the UTF-8 is
>> the PNG file translated into text, and other times it is
>> an error response.
>
> Doesn't sound you understand, or at least are showing you
> don't, what FastCGI is.
>
> Forget fastcgi, what you need is a dedicated http server
> with the built-in procssing or a http server that supports
> spawning your cgi EXE application as a special URL.

I can't take the several minutes of CGI process spawn time
for my application, (it has to load gigabytes of data into
memory before it begins) thus conventional CGI is
infeasible.

>
> You will handle standard INPUT as the encoded data.
> Simple.
>
> Example:
>
> int main(char argc, char *argv[])
> {
> DoCGI();
> return 0;
> }
>
> where DoCgi() is reads stdin and maybe environment
> strings.
>
> int DoCGI()
> {
> // get environment string, if required
> // read stdin as FORM POSTING encoding data
> // process, generate response
>
> printf("Status: 200\n");
> printf("Content-Type: text/text\n\n");
> printf"UTF8:%s\n",szResponse);
> return 0;
> }
>
> For FastCGI, you would prepare your own socket listening
> server for incoming request from the web server itself.
>
> --
> HLS


From: Peter Olcott on

"Geoff" <geoff(a)invalid.invalid> wrote in message
news:d500q5tcco5952dnl3vokflt7obvgfh50g(a)4ax.com...
> On Tue, 16 Mar 2010 17:40:54 -0400, Hector Santos
> <sant9442(a)nospam.gmail.com> wrote:
>
>>Peter Olcott wrote:
>>
>>>
>>> I would be doing FastCGI in C++, if I do it. I am
>>> considering FastCGI because I need a completely portable
>>> way
>>> for a user to browse for a PNG file to send to my
>>> server.
>>> HTML has this built in, and it is connected to CGI. As
>>> far
>>> as a protocol goes, this would be trivial. The user
>>> sends a
>>> 24-bit PNG file, the server sends back UTF-8. That's the
>>> whole protocol. Sometimes the UTF-8 is the PNG file
>>> translated into text, and other times it is an error
>>> response.
>>
>>Doesn't sound you understand, or at least are showing you
>>don't, what
>>FastCGI is.
>>
>>Forget fastcgi, what you need is a dedicated http server
>>with the
>>built-in procssing or a http server that supports spawning
>>your cgi
>>EXE application as a special URL.
>>
>>You will handle standard INPUT as the encoded data.
>>Simple.
>>
>>Example:
>>
>>int main(char argc, char *argv[])
>>{
>> DoCGI();
>> return 0;
>>}
>>
>>where DoCgi() is reads stdin and maybe environment
>>strings.
>>
>>int DoCGI()
>>{
>> // get environment string, if required
>> // read stdin as FORM POSTING encoding data
>> // process, generate response
>>
>> printf("Status: 200\n");
>> printf("Content-Type: text/text\n\n");
>> printf"UTF8:%s\n",szResponse);
>> return 0;
>>}
>>
>>For FastCGI, you would prepare your own socket listening
>>server for
>>incoming request from the web server itself.
>
> If he's going to write it in C++ as an application
> wouldn't it be
> better to write it using the ISAPI on an IIS server and
> make his OCR
> application a DLL callable from the server extension? It
> seems that
> this would solve the latency problem as well as the
> scalability
> problem since it would be a single server extension
> instance with
> multiple threads. Microsoft would claim this would be
> superior to CGI.
> This might tend to limit it to the Windows platform. I
> don't know if
> there is an ISAPI implementation on Linux.

FastCGI is portable across platforms, and most often faster
than alternatives.


From: Geoff on
On Tue, 16 Mar 2010 17:30:51 -0500, "Peter Olcott"
<NoSpam(a)OCR4Screen.com> wrote:

>
>"Geoff" <geoff(a)invalid.invalid> wrote in message
>news:d500q5tcco5952dnl3vokflt7obvgfh50g(a)4ax.com...
>> On Tue, 16 Mar 2010 17:40:54 -0400, Hector Santos
>> <sant9442(a)nospam.gmail.com> wrote:
>>
>>>Peter Olcott wrote:
>>>
>>>>
>>>> I would be doing FastCGI in C++, if I do it. I am
>>>> considering FastCGI because I need a completely portable
>>>> way
>>>> for a user to browse for a PNG file to send to my
>>>> server.
>>>> HTML has this built in, and it is connected to CGI. As
>>>> far
>>>> as a protocol goes, this would be trivial. The user
>>>> sends a
>>>> 24-bit PNG file, the server sends back UTF-8. That's the
>>>> whole protocol. Sometimes the UTF-8 is the PNG file
>>>> translated into text, and other times it is an error
>>>> response.
>>>
>>>Doesn't sound you understand, or at least are showing you
>>>don't, what
>>>FastCGI is.
>>>
>>>Forget fastcgi, what you need is a dedicated http server
>>>with the
>>>built-in procssing or a http server that supports spawning
>>>your cgi
>>>EXE application as a special URL.
>>>
>>>You will handle standard INPUT as the encoded data.
>>>Simple.
>>>
>>>Example:
>>>
>>>int main(char argc, char *argv[])
>>>{
>>> DoCGI();
>>> return 0;
>>>}
>>>
>>>where DoCgi() is reads stdin and maybe environment
>>>strings.
>>>
>>>int DoCGI()
>>>{
>>> // get environment string, if required
>>> // read stdin as FORM POSTING encoding data
>>> // process, generate response
>>>
>>> printf("Status: 200\n");
>>> printf("Content-Type: text/text\n\n");
>>> printf"UTF8:%s\n",szResponse);
>>> return 0;
>>>}
>>>
>>>For FastCGI, you would prepare your own socket listening
>>>server for
>>>incoming request from the web server itself.
>>
>> If he's going to write it in C++ as an application
>> wouldn't it be
>> better to write it using the ISAPI on an IIS server and
>> make his OCR
>> application a DLL callable from the server extension? It
>> seems that
>> this would solve the latency problem as well as the
>> scalability
>> problem since it would be a single server extension
>> instance with
>> multiple threads. Microsoft would claim this would be
>> superior to CGI.
>> This might tend to limit it to the Windows platform. I
>> don't know if
>> there is an ISAPI implementation on Linux.
>
>FastCGI is portable across platforms, and most often faster
>than alternatives.
>

There is an ISAPI implementation add-on for Apache, it's called
mod_isapi.
From: Hector Santos on
Geoff wrote:

> On Tue, 16 Mar 2010 17:40:54 -0400, Hector Santos
> <sant9442(a)nospam.gmail.com> wrote:
>
>> Peter Olcott wrote:
>>
>>> I would be doing FastCGI in C++, if I do it. I am
>>> considering FastCGI because I need a completely portable way
>>> for a user to browse for a PNG file to send to my server.
>>> HTML has this built in, and it is connected to CGI. As far
>>> as a protocol goes, this would be trivial. The user sends a
>>> 24-bit PNG file, the server sends back UTF-8. That's the
>>> whole protocol. Sometimes the UTF-8 is the PNG file
>>> translated into text, and other times it is an error
>>> response.
>> Doesn't sound you understand, or at least are showing you don't, what
>> FastCGI is.
>>
>> Forget fastcgi, what you need is a dedicated http server with the
>> built-in procssing or a http server that supports spawning your cgi
>> EXE application as a special URL.
>>
>> You will handle standard INPUT as the encoded data. Simple.
>>
>> Example:
>>
>> int main(char argc, char *argv[])
>> {
>> DoCGI();
>> return 0;
>> }
>>
>> where DoCgi() is reads stdin and maybe environment strings.
>>
>> int DoCGI()
>> {
>> // get environment string, if required
>> // read stdin as FORM POSTING encoding data
>> // process, generate response
>>
>> printf("Status: 200\n");
>> printf("Content-Type: text/text\n\n");
>> printf"UTF8:%s\n",szResponse);
>> return 0;
>> }
>>
>> For FastCGI, you would prepare your own socket listening server for
>> incoming request from the web server itself.
>
> If he's going to write it in C++ as an application wouldn't it be
> better to write it using the ISAPI on an IIS server and make his OCR
> application a DLL callable from the server extension?


yes, I was going to bring that up but it brain-flash by me. :)

Right, ISAPI would be Microsoft's form of a "fast loading" CGI concept.

> It seems that
> this would solve the latency problem as well as the scalability
> problem since it would be a single server extension instance with
> multiple threads. Microsoft would claim this would be superior to CGI.
> This might tend to limit it to the Windows platform. I don't know if
> there is an ISAPI implementation on Linux.


Some other (windows based) web servers do support a ISAPI interface,
off hand, a early version interface. Its simple a special DLL load
that special hooks. I believe I seen Apache. I don't think it will
work under a wienie OS.

If Peter wants portability, use standard C/C++, PHP, Perl or some
other server-sider scripting language. I would even look at V8,
Googles' new JIT Javascript for the server - very sweet stuff. LUA is
becoming popular but even the authors say it trade speed for portable
flexibility.



--
HLS
From: Liviu on
"Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote...
>
> I can't take the several minutes of CGI process spawn time for
> my application, (it has to load gigabytes of data into memory
> before it begins) thus conventional CGI is infeasible.

And you expect that to work on a "dedicated Linux server with 3.0 Ghz
and 2.0 GB RAM, $56.00 per month a GoDaddy.com" exactly how?

With all due respect, but after reading some of your recent posts,
including naive confusion on how to manage the lifetime of GDI
objects in a DC... I would honestly advise that you team up with
someone more versed in those pesky implementation details (and
before you wonder, no, I wouldn't ever apply). Assuming you _had_
a glorious idea, better share the glory than run it into oblivion alone.

Just my 2c,
Liviu