Casting a PHP type, new SAPI View as Markdown

Am 20.01.2015 um 23:11 schrieb Johannes Schlüter johannes@schlueters.de:

Hi,

On Tue, 2015-01-20 at 06:36 +0100, Kevin Ingwersen (Ingwie Phoenix)
wrote:

Today I have started to concept a new SAPI which I have wanted to do
in quite a while now. To learn more, here is a README:
https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md
https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md

I have to agree with Bas van Beek that I don't see the benefit of using
a custom protocol over existing ones. This protocol doesn't seem to have
less overhead than HTTP and you loose ability of using established
libraries, debugging tools, scaling tools, ...
…but you gain the headache of FastCGI. I just wasted 3 hours, trying to get this working right. It was more of an issue with the script language I am using to write the web server - but getting my head around FastCGI in the first place is a mess. When was it written and published, 1996?

Anyways:

But in order for me to work this out as good as I can - especially the
PHP API at the bottom - I need to know just a thing I could not find
within the public PHP headers: When I have an Array, now can I turn
that into an object?

What does that mean? Object in PHP-sense or in C-sense or C++-sense or
JSON? They are all different things.
Oh damn. I should ahve been more clear there. I was reffering to a PHP object.

PHP arrays essentially are a zval with a HashTable, which can be used
via zend_hash.h API, there also exist some array_* shortcuts in
zend_API.h, this changes a bit between PHP 5 and 7 so you should pick
the version.

If you want a PHP object you use the object APIs, I tend take ideas from
the reflection's implementation as it does most object things.

If you want the equivalent of $obj = (object)$array; I question whether
that makes sense (you want to write json output in the end, no? so why
do an relative expensive transformation instead of directly creating
json?) but convert_to_object() in zend_operators.c is your friend.

You want to create a JSON object? Look at the json extension, which
doesn't have an API but is trivial to copy. (mind the license of the
utf8 decoder, if needed)

Unless you have precise questions it's hard to answer expect pointing
out default resources (PHP source, Sara's book,
phpinternalsbook.com, …)
Since there is no „object syntax“ in PHP as there is in JavaScript for instance, I can’t pass an actual object and need to hack my way around and use an associative array instead. Because there is a difference in doing

$obj = new stdClasS;
$obj->propA=…;
$obj->propB=…;
func($obj);

And

func([propA=>..., propB=>...]); // my Mail program mis-fixes quotes, so I left them out

And in the end, all I need is to iterate over each key - at which I realized, I dont even need to convert it into an Object at all and can use the existing HashTable API… My failure on that.

I’d be happy to hear what you think of this concept as well. As
mentioned in the README, process on this will begin later. For now, I
am going to use helper libraries, but late ron I want to strip the
project to lesser and lesser dependencies. But it will remain being
written in C++.

One thing I noticed is that you have a dependency on some thread
libraries (while I wonder why C++08 libraries instead of C++11's thread
support).
Mostly because the C++11 support across compilers is very wobbly. TinyThread++ has the C++11 API mirrored, so it can be replaced by the STL threads on a newer compiler. But for anything that doesnt support the C++11 threads correctly, this library can do.

Using threads means pain with PHP. One thing is TSRM (while
replaced in PHP 7 with TLS)[...]
I thought TSRM was stable?

[...]the other thing is stability: A crash in one
thread will crash the whole server, in a process-based model like
FastCGI or apache mod_prefork only the single process and request will
die. Crashing PHP is trivial (infinite recursion etc.)
My idea was to use a thread per process watchdog. So a request is started, and it is given to a new thread - so it has its own PHP process running and when that one dies, it can send back an error message accordingly. PHP was not ment to run in the same process in the first place.

I also see PHP-CPP in your dependencies, that is nice but for writing
extensions, not SAPIs. And last time it checked it didn't really do good
under TSRM (haven't checked for some time)
It is fine with TSRM, actually. I only want to use it to simplify the built-in extension that allows custom messages to be sent back to the client (the instance that issued the request).

My example I use to answer SAPI questions is
https://github.com/johannes/pconn-sapi which is probably the most simple
SAPI available, working both in threaded and non-threaded mode.
Where else do you think I am getting all the SAPI docs I need in a cheat-sheet form? :)

To clarify: I mainly want to replace FastCGI. Its a pain to work with and I am spending more time on getting a proper FastCGI connection going than writing on my site. There is a good reason that programs like NodeJS allow webservers to be scripted; t make things very custom and dynamic. But since PHP’s only output seems to be FastCGI, the CLI - which doesn’t, obviously, support the header stuff - or probably something i have overlooked, I will need to write my own…

pcntl_fork() is not in the standart PHP it seems, otherwise I would have written JRP using that. But since this is going to be a general-purpose SAPI anyway, I can just write it in C++ from the get-go.

Kind regards, Ingwie