On Mon, Feb 26, 2001 at 01:31:05AM -0000, Wez Furlong wrote:
> I've been reviewing my relatively crude patch from September last year that
> provided transparent SSL socket access to PHP via the php functions
> fsockopen, fread etc. etc.
Great, I was wondering what happened, was considering doing something
myself.
> Would it be worthwhile making my changes more future proof by making an
> abstraction layer, in the
> same vein as fopen cookie (used by the zlib extension) ?
>
> php_sockbuf {
> ...
> void * cookie;
> size_t (*reader)(void * cookie, char * buffer, size_t size);
> size_t (*writer)(void * cookie, char * buffer, size_t size);
> void (*closer)(void * cookie);
> }
>
> For normal sockets, cookie would be set to the descriptor and the
> reader/writer/closer functions
> set to the regular calls. For SSL sockets the cookie would be the SSL
> pointer and the reader/writer/closer functions would be the SSL equivalents
> etc.
Sounds good to me. It's also impossible in a portable way to know if a
socket is AF_INET, AF_INET6 or AF_LOCAL, so for socket() function etc.
I've been thinking of doing something like this to store what domain
a socket is in (maybe type and protocol too). So I think that all
sockets created should have an associated structure, for the low level
PHP socket functions, we only need type at the moment, but it doesn't
hurt that much if there are some extra fields. I've been thinking of
proposing (and doing) this for a while, but I haven't had time to study
the code carefully enough to determine what's the best way.
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]
