This sounds pretty good. I'll try and look at the code this weekend. Some
of the code is really ugly especially the legacy code.
When you say there are places which need a FILE * do you mean they just
need to check the id and check that it's a FILE * or do they convert
descriptors to FILE * (can't remember if that's possible or not :).
Andi
At 02:12 AM 3/1/2001 +0000, Wez Furlong wrote:
>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]
