|
Posted by Jerry Stuckle on 09/08/06 01:37
CptDondo wrote:
> Jerry Stuckle wrote:
>
>> CptDondo wrote:
>>
>>> Let me explain my situation:
>>>
>>> I have a PHP app that generates web pages on the fly based on some
>>> data it reads from XML files. The pages are served up via a http
>>> server and displayed with a browser.
>>>
>>> I've been asked to port this to an ANSI terminal-type display,
>>> eliminating the web server and browser.
>>>
>>> Initially I thought about using C to write the app, but XML handling
>>> in C is a real PITA, plus I don't get to reuse my PHP code.
>>>
>>> So, now I want to use PHP to generate those same pages except that I
>>> don't want to send headers ever, and I need to loop waiting for
>>> characters to arrive from the keypad and display pages based on those
>>> chars...
>>>
>>> This is on an embedded platform, and I really need to be able to use
>>> a single PHP binary for both purposes (the displays are
>>> interchangeable at the hardware level; it all depends on what the
>>> customer pays for.)
>>>
>>> How do I get php to act as just another scripting language?
>>>
>>> Thanks,
>>>
>>> --Yan
>>
>>
>> Yan,
>>
>> If you're running on a web server, the headers will always be sent.
>> PHP doesn't send the headers, the web server does.
>
>
> OK, I'll play with it a bit... I've never quite figured the difference
> between php-cgi and php-cli. They both seem to do the same thing. As
> my embedded system is tipping the scales at 32 MB, I am doing what I can
> to eliminate unnecessary bloat....
>
It's pretty simple. The CGI or web server integrated interface uses the
web server for I/O operations - you don't have to open a socket to the
client, for instance. It also gets additional value from the web server.
The cli version is just that - a command line version. It doesn't run
under the web server; rather it interfaces to the command line directly.
But if you want to talk to a remote system, either that system has to
telnet/ssh into a command line prompt or you have to do your own socket
work.
>>
>> You can run it as a batch job, in which case the headers won't be
>> sent. But while you'll probably be able to use some of the code, you
>> won't be able to easily make the same program work both ways. At
>> least not without a lot of if($onwebserver){...} else {...} constructs.
>>
>> Probably better to create two files and one or more include files for
>> the code you can use in both.
>
>
> Well, the idea was to split the existing code into a front end and a
> back end, where the back end does the XML parsing and manipulation, and
> the front end handles the display end of things.
>
> That way I can reuse the back end code for both display modes without a
> snakes' nest of if ... else... :-)
>
No problem with that.
> --Yan
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[Back to original message]
|