Re: SSL -> joining sockets and files (resent)

Doing some C OOP here would probably come in handy. Short incomplete example: typedef struct _io_base {

        int (*write)(io_base *this_ptr, ....);
        int (*read)(io_base *this_ptr,....);
        int (*open)(io_base *this_ptr,....);
        int (*close)(io_base *this_ptr,.....);

} io_base; typedef struct _stdio_abstraction {

        int (*write)(io_base *this_ptr,....);
        int (*read)(io_base *this_ptr,....);
        int (*open)(io_base *this_ptr,....);
        int (*close)(io_base *this_ptr,.....);
        FILE *fp;

} stdio_abstraction; typedef struct _socket_abstraction {

        int (*write)(io_base *this_ptr,....);
        int (*read)(io_base *this_ptr,....);
        int (*open)(io_base *this_ptr,....);
        int (*close)(io_base *this_ptr,.....);
        int socket;

} socket_abstraction; typedef struct _ssl_abstraction {

        int (*write)(....);
        int (*read)(....);
        int (*open)(....);
        int (*close)(.....);
        MySSLStruct ssl;

} ssl_abstraction; typedef union _io_abstraction {

        io_base base;
        socket_abstraction socket;
        ssl_abstraction ssl;
        file_abstraction file;

} io_abstraction; Then something like: socket_abstraction s; io_abstraction *foo = &s; foo->write(foo, "blahblah"); and socket_abstraction.write() would of course cast the io_base it receives as first argument to socket_abstraction and access it's socket descriptor. I wrote this very quickly so I'm not quite sure I got it all right but it could be the general direction. Don't bash me but MS does some nice stuff this way too :) Andi At 08:03 PM 2/28/2001 +0100, Stig Venaas wrote:

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: php-dev-unsubscribe@lists.php.net For additional commands, e-mail: php-dev-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net