How not to send headers?

[CptDondo]

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

[Andy Hassall]

On Wed, 06 Sep 2006 10:12:12 -0700, CptDondo <ya*@NsOeSiPnAeMr.comwrote:

>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?

The CLI executable version of PHP doesn't output headers:

andyh@server ~ $ php test.php
look, no headers!

andyh@server ~ $ php -v
PHP 5.1.5 (cli) (built: Aug 17 2006 21:16:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Jerry Stuckle]

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.

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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Alvaro G. Vicario]

*** CptDondo escribió/wrote (Wed, 06 Sep 2006 10:12:12 -0700):

I've been asked to port this to an ANSI terminal-type display,
eliminating the web server and browser.

Headers are part of the HTTP protocol. Every piece of software that uses
HTTP *must* understand headers. So (as you mention) you must get rid of
HTTP and write your own server with your own protocol.

I haven't tested myself but this article describes how to create a PHP
script that listens in a TCP port:

http://www.litfuel.net/tutorials/sockets/sockets.php

You will find the full reference (as well as some self-explaining code
snippets) in the "Socket Functions" chapter of the PHP manual.
--
-+ http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
++ Mi sitio sobre programación web: http://bits.demogracia.com
+- Mi web de humor con rayos UVA: http://www.demogracia.com
--

[CptDondo]

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....

>
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... :-)

--Yan

[Jerry Stuckle]

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.
js*******@attglobal.net
==================