On Wed, Feb 28, 2001 at 05:12:55PM +0000, Wez Furlong wrote:
> I think what we need depends on how far we are willing to go to make
> the codebase nicer. Andi Gutmans suggested that it would be nice
> to nuke all the checks for sockets in the code; depending on how far
> we go towards that ideal, we might need to approach this in a different
> way.
Yes, and I think it's a good idea.
>
> The problem we have is that file handles in php can be regular files
> or sockets, but we have to use either stdio FILEs or unix/posix sockets
> to represent them, and the php code has to take special steps whenever
> it needs to write to a file.
>
> This causes a conflict in the case of SSL enabled sockets because the
> thing that is passed back is neither a socket nor a FILE, but does
> have an underlying socket, hence the "cookie" and socketd parameters/
> returns from the abstraction.
>
> If we expand the abstraction to cover regular files as well as sockets,
> would it be worth it?
I don't think it's that hard, but I haven't really thought it through.
What you called sockbuf could contain both socket and file stuff by
either put it all together in one large structure, or use union or a
pointer to either a file or a socket structure.
Basically you could have something like:
php_iobuf {
struct php_io_ops * ops;
void * cookie;
};
where cookie can be a pointer to file or socket structure or something
else. The code can do say ops->write(cookie, data) for both files and
sockets. You have different write functions for files, normal tcp,
SSL etc, and the cookie points to php_filebuf, php_sockbuf or what-
ever is needed for that type. The write function for files is declared
like say write(struct * php_filebuf, char *data). I think it might be
enough to have php_io_ops contain read(), write() and close() but I'm
not sure. If you do all this you can have very different code and data
for files, sockets, SSL etc. while the code that uses them simply
passes around a pointer to a php_iobuf structure (that is set up when
file is opened or socket is created (and possibly connected etc.), and
calls the write/read/close functions with the cookie.
I could try to describe it more carefully, but I think you understand
my point.
> I'm going to look into it in more depth and come back with more info
> about where we are using this stuff and where we check for sockets,
> and think some more about the open/connect/construct part of it.
Great,
Stig
--
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]
