I've just looked through the code.

The current issock stuff is a bit of a nightmare, but not too much of a problem.

Most of the codebase seems to be fairly well behaved with FP_FGETS and friends (apart 
from the interbase extension, where it does the same thing as FP_FREAD without using 

The aim is to reduce three parameters to a single parameter for the FP_ family of 
Ideally, it would be nice to do this for php_fopen_wrapper as well, and have it return 
the "php_file" abstraction we are proposing.  I'm not sure how well people will like 
in general, but thats why I'm talking about it and not changing the code right now.

Whenever an extension needs to open a file it also needs to complain if it can't open 
All over the code we have the same checks to see if it is a socket or a file, if it 
was opened, and if if wasn't complain, but first strip out a password from the 
filename/url etc. etc.

A suggestion is this:

typedef struct _php_file {
         int file_type; /* bitfield: PHP_FILE_STDIO, PHP_FILE_SOCKET */
         int (*write)(php_file *this_ptr, ....);
         int (*read)(php_file *this_ptr,....);
         int (*open)(php_file *this_ptr,....);
         int (*close)(php_file *this_ptr,.....);
         int (*seek)(php_file * this_ptr, ...); /* useful */
} php_file;

php_file * php_fopen_wrapper(char * filename, char * mode,
         int options,
         char ** opened_path,
         int report_error

Basically the same as the current implementation except that it returns an abstraction 
rather than a bunch of alternatives.
The report error flag will cause the fopen wrapper to display the error message using 
the current active function name from the scripting engine, saving a few lines of code 
for each call where error reporting is required, and increasing maintainability.

This is going to break code in 11 files, but that is relatively easy to fix.

Some code requires that we get a FILE * back (the fopen_wrapper_for_zend is one), and 
some requires a socket (the code in fsock.c), so we need a way to get those out of the 

int PHP_FILE_GET_SOCKETD(php_file *)

[the names could be PHPFILEGETSTDIOFILE, but thats a different thread... ;-)]

These could be implemented as macros, provided that all stdio based abstractions 
"descend" from a common structure where the FILE * lives at the same structure offset, 
and likewise for the socketd versions.  In the common case, there will only be one of 
each of these types anyway.

I don't think that any of this will have a special impact on win32 platforms (any more 
than unix), because we are too high level for that.

The only real problem is cleaning up the code to use the php_file abstraction instead 
of assuming it's getting a stdio fp back.

Once all this is done, the SSL code could be written as an fopen wrapper.

I'm getting tired, so I may have overlooked something glaringly obvious; please let me 
know if
I have, or if you have any other suggestions or improvements.


PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to