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
FP_FREAD).
The aim is to reduce three parameters to a single parameter for the FP_ family of
macros.
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
this
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
it.
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
php_file:
FILE * PHP_FILE_GET_STDIO_FILE(php_file *)
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.
--Wez.
--
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]
