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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
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]
